Hi,
I've just done an install of 3.0 on CentOS 6.4 using the CE installer.
It's mostly gone pretty smoothly, but, getting LDAP integration with an Active
Directory domain is proving somewhat troublesome...
While LDAP authentication against Active Directory is now, eventually, working,
LDAP authorization has some problems.
Some challenges to this point with getting LDAP going included:
1) running test_ldap_connection fails quite badly and cryptically without
RAILS_ENV set to production, which seems a little odd, defaulting to
development... Anyhow, opening a new shell to test config changes and finding a
worse failure that before was confusing at times, though a quick '.
/etc/gitorious.conf' fixed that.
2) the hints of a new LDAP wizard appeared to suggest making it easier to get this going,
however, the LDAP wizard relies on a component of sinatra-contrib, something that is only
installed in a development environment not a production environment, again, more cryptic
errors. Getting sinatra-contrib in, however, got it running, but, only on 127.0.0.1:1337,
finding "set :bind, '0.0.0.0'" resolved that.
3) All errors with ldap authentication seemed to point to complex failures in
core parts of included libraries, in reality the cause seemed to be actually
simple issues such as a problem with the bind user, introduced to allow ldap
authorization, or SSL issues. Some less cryptic errors would have proven very
useful.
4) Once AD authentication was active, there didn't appear to be a way to make
an AD user the admin. As this was a new install, there were no existing
database users, also, with disable_default: true, they wouldn't have any access
anyway. Realised I could login with an AD user, temporarily add a local admin
user, set disable_default to false, then use that local admin user to make the
AD user an admin, setting disable_default back to false afterwards.
5) The fact that changes to authentication.yml don't take effect immediately,
that I have unicorn running thanks to the CE installer, that unicorn needs to
be restarted/reloaded for changes be applied, that there is an init script for
unicorn called 'gitorious-unicorn', allowing 'service gitorious-unicorn reload'
to be used rather than finding the PID of the unicorn master and sending a USR2
signal, all took quite some time to work out, all things that you probably
don't think twice about after you've done them 1000s of times while developing,
but, which certainly encourage a degree of banging head against wall...
But, anyway, I'm at the point that AD authentication is working seemingly
perfectly, the next problem is with the authorization side...
With enable_ldap_authorization enabled, two parts of the web interface throw an
error:
1) The Teams screen, just clicking on 'Teams' gives a server error screen,
shooting out an email and logging:
NoMethodError (undefined method `active' for []:ActiveRecord::Relation):
app/controllers/groups_controller.rb:125:in `block in paginated_groups'
app/controllers/groups_controller.rb:124:in `paginated_groups'
app/controllers/groups_controller.rb:28:in `index'
2) Opening a user profile gives the same server error screen, shooting out an
email and logging:
NameError (uninitialized constant Gitorious::Authorization::LDAP):
app/models/ldap_group.rb:115:in `ldap_group_names_for_user'
app/models/ldap_group.rb:217:in `groups_for_user'
app/finders/ldap_group_finder.rb:61:in `for_user'
app/models/team.rb:70:in `method_missing'
app/controllers/users_controller.rb:51:in `block (2 levels) in show'
app/controllers/users_controller.rb:45:in `show'
I did miss these errors in log/production.log for a while due to the fact that
99.99% of that log is the following lines repeated:
Creating scope :public. Overwriting existing method MergeRequest.public.
Creating scope :open. Overwriting existing method MergeRequest.open.
which reminds me of an unexpected message from test_ldap_connection of "Both MergeRequest and
its :status machine have defined a different default for "status". Use only one or the
other for defining defaults to avoid unexpected behaviors." - Maybe just cosmetic, but,
unexpected messages without any local changes from default suggesting bad things might happen are a
little worrisome...
So, the Teams screen is failing on there potentially being no groups, but it's
not clear, and the user profile appears to be suggesting that LDAP
authorization hasn't been initialized, somewhere...
I tried packet capturing LDAP traffic to see if it was just a configuration
issue that was preventing the groups from being retrieved or similar. All the
captures showed was a search against the root, a bind using the bind user, a
search for the user at the base dn, a rebind using the discovered user cn and
that's it... Nothing related to groups in any way, not even failures...
At this point I'm wondering, 3.0 has just been released, luckily, just as I
decide to try to deploy a local instance of Gitorious, I wonder if anyone else
has tried LDAP authorization in 3.0, perhaps those that have it running in 2.x
are holding off while the new version stabilises, perhaps someone has been
trying it but enjoying some of the same fun I've been experiencing, but, is
still looking at the config changes between the version they are running and
3.0 and thinking the problem lies somewhere there...
So...
Has anyone actually made LDAP authorization work in 3.0? Is it possible? Or has
perhaps a merge been missed with the pulling together all of the new 3.0
goodness that only affects this niche userbase that wants to avoid managing the
same groups in multiple places?
Thanks,
Dan
