i've seen net::ruby like i've seen so many duplicate project.Since the
activity for net::ruby is only 76% i thought maybe it was a better
choice going with activeldap.Thank you for the pointer i will go with
Net:ruby instead.
As far as ADO i'm 100% sure i had to reinstall it.I uninstall/reinstall
ruby 3 time.For each step i have a script ready to test my install.Each
time it complain on the driver.So i had to intall --dbd_ado and it
worked after that.Also a lot of post relate on that problem.
Net::LDAP is definitely active. I just checked some new features into
it this evening. As far as ActiveLDAP is concerned, I've talked
several times with Will Drewry about refactoring it to run above
Net::LDAP. One of these days, someone will get around to doing that,
and then ActiveLDAP will also be usable without requiring a compiler.
···
On 8/28/06, Rcmn Rcmn <rcmn73@gmail.com> wrote:
i've seen net::ruby like i've seen so many duplicate project.Since the
activity for net::ruby is only 76% i thought maybe it was a better
choice going with activeldap.Thank you for the pointer i will go with
Net:ruby instead.
i've seen net::ruby like i've seen so many duplicate project.Since the
activity for net::ruby is only 76% i thought maybe it was a better
choice going with activeldap.Thank you for the pointer i will go with
Net:ruby instead.
Net::LDAP is definitely active. I just checked some new features into
it this evening. As far as ActiveLDAP is concerned, I've talked
several times with Will Drewry about refactoring it to run above
Net::LDAP. One of these days, someone will get around to doing that,
and then ActiveLDAP will also be usable without requiring a compiler.
actually u're right about Net::LDAP i just check it and noticed it too.
That would be great if ActiveLdap get accessible without compiling.
Because i almost choose to do this project with python.I was done with
my test in less than 3 hours installation included. I was ready to go
with it but i found active_directory ,a python module, easy to use but
also very limitated.
So i decided to stick with ruby a little longer.But if net::ldap is to
much to get around in short periode i'll have to change direction.
Meanwhile rdoc and this forum are valuable resources and i'm confident
i'll be able to get it done with R.
Out of curiosity, what were the specific limitations you found with
the python module active_directory? I want to make sure I didn't leave
similar limitations in Net::LDAP :-).
···
On 8/28/06, Rcmn 73 <rcmn73@gmail.com> wrote:
> That would be great if ActiveLdap get accessible without compiling.
Because i almost choose to do this project with python.I was done with
my test in less than 3 hours installation included. I was ready to go
with it but i found active_directory ,a python module, easy to use but
also very limitated.
> That would be great if ActiveLdap get accessible without compiling.
Because i almost choose to do this project with python.I was done with
my test in less than 3 hours installation included. I was ready to go
with it but i found active_directory ,a python module, easy to use but
also very limitated.
Out of curiosity, what were the specific limitations you found with
the python module active_directory? I want to make sure I didn't leave
similar limitations in Net::LDAP :-).
this module allow to just search.No add/remove function .And i run into
a limitation, 1500 max returns(That's just what i've been experiencing).
Thanks for the information. Net::LDAP has the full set of LDAP
operations. I'm a little surprised that you are able to get 1500 entries
per search, though. The usual limitation with ActiveDirectory is 1000.
Many tools have this limitation, which is caused by a lack of support
for RFC-2696. Net::LDAP doesn't have this limitation, and neither do the
more recent versions of ldapsearch.
I've never heard of 1500, though, unless your A/D configuration has been
tweaked.
This is a very good new that Net::LDAP does not have this limitation.
As our Active directory limitation it has probably limitated to
1500.Using PHP or the DS command's i can get various result but i was
never able to get more than 1500+.And depending of the periode of the
day PHP or DS cmd would just died without any return.Anyway with the
python module i get a consitent 1500.So maybe as u mention the
limitation is an AD setting.
So i assume i will run into that limitation also with Net::LDAP...Or
Net::LDAP process search by a different way and avoid this sort of
limitation ? By getting a set of 100 then an other 100 etc ? Or is that
impossible?
Net::LDAP correctly implements the "paged-search" control, so there is
no limit on the number of entries you can query from A/D. If your set
is particularly large (more than 10,000 for example), then I recommend
you use the :return_result => false flag. See the rdocs for
Net::LDAP#search for more information.
···
On 8/29/06, Rcmn 73 <rcmn73@gmail.com> wrote:
> This is a very good new that Net::LDAP does not have this limitation.
As our Active directory limitation it has probably limitated to
1500.Using PHP or the DS command's i can get various result but i was
never able to get more than 1500+.And depending of the periode of the
day PHP or DS cmd would just died without any return.Anyway with the
python module i get a consitent 1500.So maybe as u mention the
limitation is an AD setting.
So i assume i will run into that limitation also with Net::LDAP...Or
Net::LDAP process search by a different way and avoid this sort of
limitation ? By getting a set of 100 then an other 100 etc ? Or is that
impossible?
I forgot to mention: paged searches are automatic in Net::LDAP. You
don't have to write your code differently to get them.
···
On 8/29/06, Rcmn 73 <rcmn73@gmail.com> wrote:
> This is a very good new that Net::LDAP does not have this limitation.
As our Active directory limitation it has probably limitated to
1500.Using PHP or the DS command's i can get various result but i was
never able to get more than 1500+.And depending of the periode of the
day PHP or DS cmd would just died without any return.Anyway with the
python module i get a consitent 1500.So maybe as u mention the
limitation is an AD setting.
So i assume i will run into that limitation also with Net::LDAP...Or
Net::LDAP process search by a different way and avoid this sort of
limitation ? By getting a set of 100 then an other 100 etc ? Or is that
impossible?
Does Net::LDAP have a way of dealing with this on v2 servers? or servers that don't yet implement paged results? Thanks.
-jason
···
On Aug 29, 2006, at 10:45 AM, Francis Cianfrocca wrote:
On 8/29/06, Rcmn 73 <rcmn73@gmail.com> wrote:
> This is a very good new that Net::LDAP does not have this limitation.
As our Active directory limitation it has probably limitated to
1500.Using PHP or the DS command's i can get various result but i was
never able to get more than 1500+.And depending of the periode of the
day PHP or DS cmd would just died without any return.Anyway with the
python module i get a consitent 1500.So maybe as u mention the
limitation is an AD setting.
So i assume i will run into that limitation also with Net::LDAP...Or
Net::LDAP process search by a different way and avoid this sort of
limitation ? By getting a set of 100 then an other 100 etc ? Or is that
impossible?
I forgot to mention: paged searches are automatic in Net::LDAP. You
don't have to write your code differently to get them.
On 8/29/06, Rcmn 73 <rcmn73@gmail.com> wrote:
> This is a very good new that Net::LDAP does not have this limitation.
As our Active directory limitation it has probably limitated to
1500.Using PHP or the DS command's i can get various result but i was
never able to get more than 1500+.And depending of the periode of the
day PHP or DS cmd would just died without any return.Anyway with the
python module i get a consitent 1500.So maybe as u mention the
limitation is an AD setting.
So i assume i will run into that limitation also with Net::LDAP...Or
Net::LDAP process search by a different way and avoid this sort of
limitation ? By getting a set of 100 then an other 100 etc ? Or is that
impossible?
I forgot to mention: paged searches are automatic in Net::LDAP. You
don't have to write your code differently to get them.
This is great informations and specially great news.Thank you very much
for the information and the great work.
That's two different questions. Net::LDAP only implements V3. Do you
actually have a V2 server??? If so, I'd be really appreciative if you
could try Net::LDAP against it and see what happens. (Is it one of
those early Netscape Enterprise Directories?)
Paged results: Net::LDAP specifies the control as "noncritical," which
means it will be ignored by servers that don't recognize it (such as
OpenLDAP versions other than very recent ones). So it will
interoperate seamlessly with these servers.
···
On 8/29/06, Jason Rohwedder <jro@codegrinder.com> wrote:
Does Net::LDAP have a way of dealing with this on v2 servers? or
servers that don't yet implement paged results? Thanks.
If you try the library and have problems, please tell me, either here
or by private email. A lot of people have done so already, and it
makes the library better for everyone.
···
On 8/29/06, Rcmn 73 <rcmn73@gmail.com> wrote:
> This is great informations and specially great news.Thank you very much
I don't have a V2 server; I was more concerned with the versions of OpenLDAP that don't recognize it... Is there a way to deal with getting all the results from a not recent OpenLDAP server? Thanks.
-jason
···
On Aug 29, 2006, at 11:23 AM, Francis Cianfrocca wrote:
On 8/29/06, Jason Rohwedder <jro@codegrinder.com> wrote:
Does Net::LDAP have a way of dealing with this on v2 servers? or
servers that don't yet implement paged results? Thanks.
-jason
That's two different questions. Net::LDAP only implements V3. Do you
actually have a V2 server??? If so, I'd be really appreciative if you
could try Net::LDAP against it and see what happens. (Is it one of
those early Netscape Enterprise Directories?)
Paged results: Net::LDAP specifies the control as "noncritical," which
means it will be ignored by servers that don't recognize it (such as
OpenLDAP versions other than very recent ones). So it will
interoperate seamlessly with these servers.
Net::LDAP works seamlessly with older OpenLDAP servers that don't
support paged queries. I know because I use one in production all day
long.
For what it's worth (and at the risk of igniting some flames): I'm
quite convinced that paged-searches were invented by Microsoft
primarily to lighten the load on their somewhat, ummm... "challenging"
LDAP implementation. (Bear in mind that LDAP support was tacked onto
A/D after the core was designed.) If you read the paged-search RFC,
they blow some smoke about lessening the load on *client*
implementations.
OpenLDAP added paged searches recently, but their older
implementations don't suffer particularly for the lack. I routinely
query 100,000 entries out of an old OpenLDAP on a low-end workstation
to test Net::LDAP, and it doesn't break a sweat. It's not fast, but
it's stable.
···
On 8/29/06, Jason Rohwedder <jro@codegrinder.com> wrote:
I don't have a V2 server; I was more concerned with the versions of
OpenLDAP that don't recognize it... Is there a way to deal with
getting all the results from a not recent OpenLDAP server? Thanks.
Excellent.. I'll have to start retrofitting some of my ruby/ldap based scripts over, and playin' around.
-jason
···
On Aug 29, 2006, at 12:14 PM, Francis Cianfrocca wrote:
On 8/29/06, Jason Rohwedder <jro@codegrinder.com> wrote:
I don't have a V2 server; I was more concerned with the versions of
OpenLDAP that don't recognize it... Is there a way to deal with
getting all the results from a not recent OpenLDAP server? Thanks.
Net::LDAP works seamlessly with older OpenLDAP servers that don't
support paged queries. I know because I use one in production all day
long.
For what it's worth (and at the risk of igniting some flames): I'm
quite convinced that paged-searches were invented by Microsoft
primarily to lighten the load on their somewhat, ummm... "challenging"
LDAP implementation. (Bear in mind that LDAP support was tacked onto
A/D after the core was designed.) If you read the paged-search RFC,
they blow some smoke about lessening the load on *client*
implementations.
OpenLDAP added paged searches recently, but their older
implementations don't suffer particularly for the lack. I routinely
query 100,000 entries out of an old OpenLDAP on a low-end workstation
to test Net::LDAP, and it doesn't break a sweat. It's not fast, but
it's stable.