On Wed, Jul 4, 2012 at 1:01 AM, Claus Folke Brobak <[email protected]>wrote:
> In our company the desktop computers are running primarily Windows, the > servers a mix of Windows, AIX, Linux and z/OS. Computers, groups and and > users are defined in Active Directory. As such we are probably not very > different from a lot of other companies. > > Active Directory can be accessed using LDAP and so far I have been using > Ruby and the "net-ldap" gem for extracting information from Active > Directory. However, the following comment from R. O'Connell has made me > question the wisdom in using Ruby for LDAP access in the future: > > --- quote begin --- > > Interest in LDAP over the last few years has been sharply declining, > especially in the Ruby community who tries to avoid enterprise-y type > things as much as possible. There was a big push when 1.9 came out to > make it functional since the library was completely broken, but other > than that LDAP is generally eschewed in Ruby in favor of simpler things > like Mongo for document stores (which LDAP really is) or Redis for > simple key-value authentication. I'll try and keep up on patches and bug > fixes, but I wouldn't expect a huge push simply due to the fact that > LDAP is simply becoming irrelevant. > > --- quote end --- > > The quote is taken from this thread: > > > http://groups.google.com/group/ruby-ldap/browse_thread/thread/f99381035f9032ea > > Now, Active Directory is not going away anytime soon, so I should like > to hear the opinion and suggestions from forum members about using Ruby > for LDAP/Active Directory access. > > -- > Posted via http://www.ruby-forum.com/. > > First I've just got a tangent/gripe, but when I first looked for a library to use for LDAP use a few years ago, I found the "namespace" confusing: First take the most popular rubygem (when searching rubygems.org with the term "ldap"). The winner is the "net-ldap" gem. The official homepage is " http://rubyldap.com/"; and the code repository is hosted in a Github repository named "ruby-net-ldap". The Github repository is hosted under the user "RoryO" according to the metadata from the gem as displayed on rubygems.org but is hosted under the organization "ruby-ldap" according to the link on the homepage (http://rubyldap.com/). The "ruby-ldap" Github organization has just the one member, user RoryO, so clearly the project owner has just done some reorganization of the gem. That's cool. Plus, the metadata in the gemspec file downloaded as I just installed the latest version (0.3.1) of the gem appears to be updated and lists the current Github repository URL as the homepage. I guess that rubygems.org's metadata is just out of date? Anyhow, the point of all this is to point out the names that my brain associates with this library: net-ldap (official gem name and accurate reference to the name of the class(es) implemented, Net::LDAP), rubyldap (homepage's domain), ruby-ldap (w/hyphen, name of organization that owns official code repository). In isolation, this wouldn't be a problem. However, the next most popular LDAP client gem (I'm skipping ruby-net-ldap which appears to just be the old, original, net-ldap gem; I'm also skipping activeldap which simply has to wrap another LDAP client library to provide an ActiveRecord-like interface) -- okay, I'm starting this sentence over :). (Clearing throat)... However, the next most popular, unique, LDAP client gem is called "ruby-ldap". This is the name that the "net-ldap" gem is using as their homepage's domain and Github organization name. So, without being careful, it is easy to start to get confused. The "ruby-ldap" gem is at least self-consistent and uses the same name for its RubyForge project name and Github repository name. The docs call the library "Ruby/LDAP", this one being a ruby C extension that wraps access to other, existing LDAP libraries. I guess the proper "name" (I'm referencing the README from the activeldap gem) is "Ruby/LDAP" for the "ruby-ldap" C extension and "Net::LDAP" for the "net-ldap" pure-ruby LDAP-client gem that used to be called "ruby-net-ldap". So, yeah. This is a tangential naming gripe. I guess it's also a question: why does "net-ldap" use the "ruby-ldap" name? I understand that some library authors like to stick the underlying language's name in the library name for domain name and search/SEO clarity? Hmm. Anyhow, a little more on-topic, I used the "net-ldap" gem at the last company I worked for as our email system utilized our central LDAP database and I wanted to centralize all authentication. So, regardless of my grip/confusion with the name, I'm grateful to the author(s) for their work. I understand that for a large enterprise it may be frustrating to not have a more full-fleshed solution. I noted in the discussion thread you linked to that someone mentioned that a more ideal implementation might be EventMachine-based (as well as fully featured). However, the last message from "danabr" in the thread made it appear that others recognize that LDAP isn't going away but wanted to first focus development efforts on project cleanup (refactoring and adding test coverage). I also agree that LDAP (and good support for it) is and will continue to be important, even if new projects and systems don't tend to use it (as one poster suggested). However, it seems to me that it's a manpower issue more than anything. Those of us ruby developers who work(ed) doing "Enterprise-y" coding with ruby often have to make do with whatever tech is currently already available. Only to the degree that we can sell the idea of contributing to the Open Source community can we get time to contribute to and use projects like "net-ldap". Also, if an existing project works for us (a small enterprise in my case, who's LDAP-query load was small enough that net-ldap worked just fine) we don't tend to contribute once our itch is scratched. Lastly, though I acknowledge that ActiveDirectory (and by extension LDAP) won't be going away soon, I'd sure like to see (or help work toward) an alternative to AD/LDAP for user/group identity/policy management. I'm sure there are small 3rd-party and/or open source solutions that attempt to do some parts of this but that don't succeed well enough to displace AD in any sizeable enterprise. I don't consider Samba any kind of replacement strategy either since it primarily just tries to compatibly implement Microsoft's equivalent software (plus a samba-based NT4-style PDC isn't AD by any means). However, the technology landscape is always changing and who knows what kind of workstations enterprises may deploy in the future and what opportunities may exists to create alternative policy management frameworks. So, yeah. I'd guess a lot of rubyists like to work on something they consider really forward-thinking (I know I do) as opposed to fleshing out robust libraries for status quo technology. But, on a pragmatic side, we have to exist and interact with today's actual real technology, most of which will still be around for years to come as well. So, there's room and need to flesh out "net-ldap"'s code base as well as to have people taking entirely different views of the underlying technical problem and working toward a cool new offering. Personally I really dislike LDAP compared to simpler, schema-less document databases and/or key-value stores and/or traditional relational databases, depending on the specific need. I don't dislike LDAP in principle -- I actually like the concept and think a structured, schema-based, hierarchical, distributed database would be "just the thing" for solving some problems. I think I just dislike the underlying query syntax and the LDIF format. In other words, I dislike details, not the underlying concept. Well, my combination of random complaints, thanks, opinions, and comments regarding LDAP, ActiveDirectory, and the "net-ldap" gem are over. I don't have any conclusions to offer or great, ground-breaking thoughts besides pointing out the obvious. Hopefully development on "net-ldap" continues and the "manpower" can be found to do so. I currently don't have an LDAP itch so I'm distracted by other projects/goals (though that could change as I'm moving and consequently need to find a new job). Good luck solving your own set of problems and finding the best solution (whether ruby-based or not). -- Kendall Gifford [email protected] -- You received this message because you are subscribed to the Google Groups ruby-talk-google group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at https://groups.google.com/d/forum/ruby-talk-google?hl=en
