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.

In fiddling with ruby, I noticed that the method names can be really interesting – rails (maybe others too, dunno) has some methods that look like:

object.stop?

which is typically used to return a boolean indicating wether or not “stop” is true. Ok, cool. Another interesting method call is

object.close

which appears to be identical to

object.close()

. That part really confused me, and I’m still not sure I have it completely clear.

In python

object.close

and

object.close()

are two very different things. The first is a reference to the instance method close – which you can pass around. The second is a specific invocation to the instance method. In ruby the parentheses appear to be optional if there are no arguments getting passed in to the function.

Update:

Dave Slorah pointed out that the parantheses option thing extends beyond just the no-argument methods – it applies all over the place!

irb(main):010:0> def foo(bar,baz)
irb(main):011:1>   puts bar
irb(main):012:1>   puts baz
irb(main):013:1> end
=> nil
irb(main):014:0> foo "hello", "world"
hello
world

My first thought it “Wow – that’s almost Objective-C like…”

I’ve spent most of the afternoon re-aquainting myself with Mac programming idioms, and generally getting myself into a veritable froth of possibilityand over-imagination about the CoreAnimation technologies.

Outside of that, I finally backtracked into the world of Ruby on Rails to figure out why all the examples in the books were completely screwed up for me. It turns out that a basic stepping stone in most of those tutorials is the “dynamic scaffolding” bit. In the world of the Django frameworks, this is sort of a cross between the Admin functionality that’s implied from all models there and a “insta-crud” framework that’s for a general user’s benefit.

Regardless, when I got to that point in the rails world, the demos just all broke and went to hell – and as a rank newbie, I hadn’t a freakin’ clue of what was going on and how to fix it.Today I finally pinned it down. Taking some time away from it gave me a little perspective (as in I wasn’t muttering about how this rails thing sucks) and I got the skinny on the ruby forums. In a nutshell, dynamic scaffolding doesn’t exist in Rails 2.x – but you can generate a static scaffolding with rails generator code.

I’m certainly not quite used to “script/generate …” which seems to frequent the rails world of newbie examples. It does get a hell of a lot done for you, but I sort of feel like I’m missing the boat on what’s actually happening and what the defaults/conventions of rails are. Just working through it, I guess, is the best way to learn.

I think I picked a poor time to dive into and start learning Ruby on Rails. I’ve been reading and going through exercises from a fresh install and the plethora of great examples aren’t matching the new environment. It’s pretty close, but that little off from “right on the money” can be a real pain.

I’ve been primarily learning from Ruby on Rails: Up and Running, which is a pretty good text for getting started. The only downside is that it apparently just missed the Rails 2.0 thing with a couple of examples.

I picked up my copy of the Pickaxe book four years ago – it’s even signed by Dave Thomas. I started to learn and poke at it a couple of times, but didn’t make any serious forays into it. The past couple of days is changing that. After a deep dark struggle with myself, I decided that I needed to learn and know a lot more about Ruby and Ruby on Rails. I’m not abandoning Django at all – but I suspect that knowing another framework with a similar mindset and a different language will do nothing but good for me. Shoot – I’ve got outstanding work to get done in the Django world on our Django Queue Service… can’t back out now.

The dark seed behind the whole ruby thing is  - I suspect more people would be willing to learn it than Django. It’s got more hype, more books, more caché. I’m not even going to claim one is superior to the other – both do some rockin’ good stuff – but Rails has the word. For myself, and for projects that I’ll be supporting either alone or not intending to hand off – Django is the thing. It’s my secret web-app weapon. Not unlike cocoa for most mac programmers. It’s amazing what a single person can get done with the right tools. There are some projects coming up, however, where I’m going to have to convince some others to pick up and learn. Maybe even support. I think at least being able to knock out webapps in Ruby with Rails will be a benefit there.

The oddest thing for me right now is the syntactic  sugar that ruby uses for blocks, iterators and closures. It’s neat and darned concise – I’ll give it that, but it sure doesn’t feel natural. The other thing that I think will take a little getting used to is the library set. It’s a great, beautiful library if API’s to get things done, but the capitalization is causing me to stumble all over the damn place. The language, although a little foreign on my tongue right now, is pretty cool. I think Matz did a fine job of coming up with his Babel-17.

I think it’ll be a while before I’m able to sling code with like other ruby natives, but I’m guessing not that long at all really. The biggest stumbling block for the whole “convention over configuration” thing is just learning the damn conventions. And there’s a nice pile of books available to help with that.