From: Kendall Gifford Date: 2012-07-05T08:09:01+09:00 Subject: Re: Ruby for LDAP access? --14dae9340e05a3144404c4091d5e Content-Type: text/plain; charset=UTF-8 On Wed, Jul 4, 2012 at 1:01 AM, Claus Folke Brobak 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 zettabyte@gmail.com --14dae9340e05a3144404c4091d5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 4, 2012 at 1:01 AM, Claus Folke Brob= ak <lists@ruby-forum.com> 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 Activ= e
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 bu= g
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/grip= e, but when I first looked for a library to use for LDAP use a few years ag= o, I found the "namespace" confusing:

First take the most = popular rubygem (when searching rubygems.or= g with the term "ldap"). The winner is the "net-ldap&quo= t; gem. The official homepage is "htt= p://rubyldap.com/" and the code repository is hosted in a Github r= epository 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 downloa= ded 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 gue= ss 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 a= ssociates with this library: net-ldap (official gem name and accurate refer= ence to the name of the class(es) implemented, Net::LDAP), rubyldap (homepa= ge's domain), ruby-ldap (w/hyphen, name of organization that owns offic= ial code repository).

In isolation, this wouldn't be a problem. However, the next most po= pular 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 usi= ng 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 do= cs call the library "Ruby/LDAP", this one being a ruby C extensio= n that wraps access to other, existing LDAP libraries.

I guess the proper "name" (I'm referencing the README fro= m the activeldap gem) is "Ruby/LDAP" for the "ruby-ldap"= ; C extension and "Net::LDAP" for the "net-ldap" pure-r= uby 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 qu= estion: 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 thei= r work.

I understand that for a large enterprise it may be frustrating to not h= ave a more full-fleshed solution. I noted in the discussion thread you link= ed to that someone mentioned that a more ideal implementation might be Even= tMachine-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 t= o 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 &q= uot;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 t= he idea of contributing to the Open Source community can we get time to con= tribute 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 LDA= P) won't be going away soon, I'd sure like to see (or help work tow= ard) 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 att= empt to do some parts of this but that don't succeed well enough to dis= place AD in any sizeable enterprise. I don't consider Samba any kind of= replacement strategy either since it primarily just tries to compatibly im= plement Microsoft's equivalent software (plus a samba-based NT4-style P= DC 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 m= anagement frameworks.

So, yeah. I'd guess a lot of rubyists like to work on something the= y 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 h= ave 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 ha= ve people taking entirely different views of the underlying technical probl= em and working toward a cool new offering. Personally I really dislike LDAP= compared to simpler, schema-less document databases and/or key-value store= s and/or traditional relational databases, depending on the specific need. = I don't dislike LDAP in principle -- I actually like the concept and th= ink a structured, schema-based, hierarchical, distributed database would be= "just the thing" for solving some problems. I think I just disli= ke the underlying query syntax and the LDIF format. In other words, I disli= ke details, not the underlying concept.

Well, my combination of random complaints, thanks, opinions, and commen= ts regarding LDAP, ActiveDirectory, and the "net-ldap" gem are ov= er. I don't have any conclusions to offer or great, ground-breaking tho= ughts 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 projec= ts/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 solutio= n (whether ruby-based or not).

--
Kendall Gifford
zettabyte@gmail.com
--14dae9340e05a3144404c4091d5e--