perl-ldap-dev

Re: Sockets leaking?

[Stephen B. <st...@br...>]

I think I have found the bug -- see below.

On Monday 06 January 2003 14:58, Chris Ridd wrote:
> On 6/1/03 1:25 pm, Stephen Brandon <st...@br...>
>
> wrote:
> > Hi,
> >
> > I am using the perl-back backend to OpenLDAP's slapd, and using perl-ldap
> > to forward some requests on to another LDAP server.
> >
> > I need to be able to cope with non-local servers going on- and off-line,
> > while keeping a persistant connection where possible.
> >
> > As far as I can see, there seems to be no way to totally tear down one of
> > my LDAP connections, if the foreign server stops responding.
> >
> > Here's the order of operations:
> >
> > - foreign server stops responding
> > - perl-ldap attempts a "search" on $ldap, which was previously a valid
> > connection
> > - search fails with code 1, "I/O Error Connection reset by peer"
> > - I attempt to do an unbind(), which appears to succeed (no error
> > message) - lsof shows the socket as "no PCB, CANTSENDMORE, CANTRCVMORE"
> > - I make a new connection to the server, which succeeds this time
> > - lsof STILL shows the socket as "no PCB, CANTSENDMORE, CANTRCVMORE",
> > though there's now a new socket as well
> > - these unallocated sockets continue to stack up till the process is out
> > of fd's
> >
> > So, why aren't the sockets being closed? Is this supposed to happen via
> > garbage collection? If so, the process of creating a new perl-ldap
> > instance in $ldap seems not to be triggering GC in my case...
> >
> > As far as I can see I am not creating any other references to $ldap
> > itself, though I am caching arrays of strings returned from the search
> > results - but I don't imagine this creates references to $ldap.
>
> Search result objects (Net::LDAP::Search) have parent references to the
> $ldap object that created them ($res->parent). I don't think the Entry
> objects themselves have this parent reference. What precisely are you
> caching from the search results?
 
YES -- that's it -- it's the "message" hashes held in ::LDAP objects that 
have the parent references. If these messages are still contained in the 
object, then it won't automatically be destroyed.

I had to do the following after finishing with an LDAP object:

               $ldap->{net_ldap_mesg} = "";

Then I could create a new ldap object in $ldap, and the 1st one is 
deallocated properly (at last).

Is there a more official way of doing this? I can't see anything particular 
in the source...

So far, I consider this a bug. I can see plenty of occasions where people 
will have made a number of connections and the objects will not have been 
deallocated because of this issue.

Cheers,
Stephen Brandon


>
> > To fix this for the time being, after getting the Connection Reset error
> > I (i) call $ldap->unbind, and (ii) close $ldap->socket()
> >
> > This seems to stop the file descriptor problem, but I am concerned that
> > there may be a larger scale memory leak going on.
> >
> > - Can anyone shed any light on this?
> > - Should there be some other method in perl-ldap that does a more
> > thorough, explicit cleanup?
>
> This all ought to happen when the Net::LDAP object is destroyed, eg it goes
> out of scope. Try adding a Net::LDAP::DESTROY method to see when (if!) it
> gets called.
>
> Cheers,
>
> Chris

Re: Sockets leaking?

[Stephen B. <st...@br...>]

Hi,

To demonstrate the problem, here's a small snippet of code. You also need an 
ldap server that you can quickly and interactively stop and start, so that it 
can get a connection the first time, but fail on the 2nd search because the 
connection was broken, then reconnect (the server must be up again at that 
point).

#!/usr/bin/perl

use Net::LDAP;

sub ldapsearch
{
        return $ldap->search (  # perform a search
                base   => "o=ku",
                filter => $origFilter,
                attrs => ['dn','cn','objectClass', 
'sn','givenName','initials','fullName','mail'] 
                );
}

sub new_connection
{
        $ldap = new Net::LDAP('myserver',
                port => 33344,
                onerror => 'warn',
                timeout => 2000
) or print STDERR "Error trying to make LDAP connection: $@\n\n";
}

$origFilter = "cn=16368";

new_connection();
$mesg = ldapsearch();

print STDERR "snoooore...\n";
# during this time I stop and restart the ldap server
sleep 10;
print STDERR "awake!\n";
$mesg = ldapsearch();
if ($mesg->code == $ldap->LDAP_OPERATIONS_ERROR() ) {
                print STDERR "Connection failed... will destroy and ". 
"reconnect\n";

                new_connection();
                if (defined $ldap) { print STDERR "got it second time 
round\n";}
}

===========================================
I also added a DESTROY method to LDAP.pm.

Results:
======
snoooore...
awake!
I/O Error Connection reset by peer  at test.pl line 7
Connection failed... will destroy connection and reconnect
got it second time round
DEEEEEEEEEEEEEEEEEEEEEESSSSSSTROY LDAP object!!!


DEEEEEEEEEEEEEEEEEEEEEESSSSSSTROY LDAP object!!!

==========================================

Note that the object is not destroyed BEFORE the "got it 2nd time round" as 
it should have been. I suspect that both objects were only destroyed at the 
very end as the program exits.

I also tested just doing new_connection() a couple of times on a continuously 
available server - and it destroys the object in the right places. It's just 
when the socket has become invalid that it does not deallocate.

Cheers,
Stephen Brandon

Re: Sockets leaking?

[Graham B. <gb...@po...>]

On Mon, Jan 06, 2003 at 01:25:46PM +0000, Stephen Brandon wrote:
> To fix this for the time being, after getting the Connection Reset error I 
> (i) call $ldap->unbind, and (ii) close $ldap->socket()
> 
> This seems to stop the file descriptor problem, but I am concerned that there 
> may be a larger scale memory leak going on.

If closing the socket explicitly is solving the problem of leaked fd's then that does
indicate that there is a bigger problem. Somewhere something is holding a reference
to the socket, or Net::LDAP object.

> - Can anyone shed any light on this?

Doing a Data::dumper of the Net::LDAP object where you are currently doing the close
would show if there were any internal circular references. If there is not
then it must be something outside of Net::LDAP that is holding that reference.

> - Should there be some other method in perl-ldap that does a more thorough, 
> explicit cleanup?

That would not really help. If there is something holding a reference to the Net::LDAP
object, you have a leak no matter how good Net::LDAP is being.

Graham.

Re: Sockets leaking?

[Stephen B. <st...@br...>]

On Monday 06 January 2003 14:58, Chris Ridd wrote:
> On 6/1/03 1:25 pm, Stephen Brandon <st...@br...>
> wrote:

> > So, why aren't the sockets being closed? Is this supposed to happen via
> > garbage collection? If so, the process of creating a new perl-ldap
> > instance in $ldap seems not to be triggering GC in my case...
> >
> > As far as I can see I am not creating any other references to $ldap
> > itself, though I am caching arrays of strings returned from the search
> > results - but I don't imagine this creates references to $ldap.
>
> Search result objects (Net::LDAP::Search) have parent references to the
> $ldap object that created them ($res->parent). I don't think the Entry
> objects themselves have this parent reference. What precisely are you
> caching from the search results?

ok, I have just made the search results into a "my" variable so they do not 
get remembered between sessions - no effect. I am not caching these search 
result objects at all.

The individual entries are parsed to get the attribute and value strings, and 
I simply keep a big array/hash of these values. So I don't think they would 
be the problem.

> > To fix this for the time being, after getting the Connection Reset error
> > I (i) call $ldap->unbind, and (ii) close $ldap->socket()
> >
> > This seems to stop the file descriptor problem, but I am concerned that
> > there may be a larger scale memory leak going on.
> >
> > - Can anyone shed any light on this?
> > - Should there be some other method in perl-ldap that does a more
> > thorough, explicit cleanup?
>
> This all ought to happen when the Net::LDAP object is destroyed, eg it goes
> out of scope. Try adding a Net::LDAP::DESTROY method to see when (if!) it
> gets called.

Will do.

Cheers,
Stephen

Re: Insecure dependency in perl-ldap 0.21+

[Graham B. <gb...@po...>]

On Mon, Jan 06, 2003 at 04:04:40PM +0000, Chris Ridd wrote:
> 
> The change looks safe enough to me, but Graham might have an opinion on it.

It looks fine to me. I am intrigued why this fixes the problem though
as it changes little.

Graham.

Re: Insecure dependency in perl-ldap 0.21+

[Chris R. <chr...@ma...>]

On 6/1/03 9:35 am, Ziya Suzen <zi...@ri...> wrote:

> On 2003-01-06 09:13:24 +0000, Chris Ridd wrote:
>> On 6/1/03 8:40 am, Ziya Suzen <zi...@ri...> wrote:
>>> Hi,
>>> 
>>> Thanks for the quick response.
>>> 
>>> [...]
>>> 
>>>> Is your patch still needed with the current version of perl-ldap - 0.26?
>>> 
>>> Yes.
>>> 
>>> Long answer is; Message.pm has remained the same since 'version 1.4,
>>> 2000/09/12 09:17:09' looking at cvs. I guess we can say;
>>> 
>>> Patch is needed with any version of perl-ldap where
>>> $Net::LDAP::Message::VERSION == 1.05
>>> 
>>> Cheers,
>>> 
>>> Ziya.
>>> 
>>> 
>> 
>> I was wondering if there was anything else in 0.26 which might have made the
>> problem "go away" (I can't think how, but...) You're probably right about
>> this affecting all subsequent versions, but it would still be good to check
>> if the fix is actually needed in 0.26.
> 
> Sorry for the confusion. Seems like the version I have been working
> on is '0.26'.

:-)

The change looks safe enough to me, but Graham might have an opinion on it.

Cheers,

Chris

Re: Sockets leaking?

[Chris R. <chr...@ma...>]

On 6/1/03 1:25 pm, Stephen Brandon <st...@br...>
wrote:

> Hi,
> 
> I am using the perl-back backend to OpenLDAP's slapd, and using perl-ldap to
> forward some requests on to another LDAP server.
> 
> I need to be able to cope with non-local servers going on- and off-line,
> while keeping a persistant connection where possible.
> 
> As far as I can see, there seems to be no way to totally tear down one of my
> LDAP connections, if the foreign server stops responding.
> 
> Here's the order of operations:
> 
> - foreign server stops responding
> - perl-ldap attempts a "search" on $ldap, which was previously a valid
> connection
> - search fails with code 1, "I/O Error Connection reset by peer"
> - I attempt to do an unbind(), which appears to succeed (no error message)
> - lsof shows the socket as "no PCB, CANTSENDMORE, CANTRCVMORE"
> - I make a new connection to the server, which succeeds this time
> - lsof STILL shows the socket as "no PCB, CANTSENDMORE, CANTRCVMORE", though
> there's now a new socket as well
> - these unallocated sockets continue to stack up till the process is out of
> fd's
> 
> So, why aren't the sockets being closed? Is this supposed to happen via
> garbage collection? If so, the process of creating a new perl-ldap instance
> in $ldap seems not to be triggering GC in my case...
> 
> As far as I can see I am not creating any other references to $ldap itself,
> though I am caching arrays of strings returned from the search results - but
> I don't imagine this creates references to $ldap.

Search result objects (Net::LDAP::Search) have parent references to the
$ldap object that created them ($res->parent). I don't think the Entry
objects themselves have this parent reference. What precisely are you
caching from the search results?

> To fix this for the time being, after getting the Connection Reset error I
> (i) call $ldap->unbind, and (ii) close $ldap->socket()
> 
> This seems to stop the file descriptor problem, but I am concerned that there
> may be a larger scale memory leak going on.
> 
> - Can anyone shed any light on this?
> - Should there be some other method in perl-ldap that does a more thorough,
> explicit cleanup?

This all ought to happen when the Net::LDAP object is destroyed, eg it goes
out of scope. Try adding a Net::LDAP::DESTROY method to see when (if!) it
gets called.

Cheers,

Chris

Sockets leaking?

[Stephen B. <st...@br...>]

Hi,

I am using the perl-back backend to OpenLDAP's slapd, and using perl-ldap to 
forward some requests on to another LDAP server.

I need to be able to cope with non-local servers going on- and off-line, 
while keeping a persistant connection where possible.

As far as I can see, there seems to be no way to totally tear down one of my 
LDAP connections, if the foreign server stops responding.

Here's the order of operations:

- foreign server stops responding
- perl-ldap attempts a "search" on $ldap, which was previously a valid 
connection
- search fails with code 1, "I/O Error Connection reset by peer"
- I attempt to do an unbind(), which appears to succeed (no error message)
- lsof shows the socket as "no PCB, CANTSENDMORE, CANTRCVMORE"
- I make a new connection to the server, which succeeds this time
- lsof STILL shows the socket as "no PCB, CANTSENDMORE, CANTRCVMORE", though 
there's now a new socket as well
- these unallocated sockets continue to stack up till the process is out of 
fd's

So, why aren't the sockets being closed? Is this supposed to happen via 
garbage collection? If so, the process of creating a new perl-ldap instance 
in $ldap seems not to be triggering GC in my case...

As far as I can see I am not creating any other references to $ldap itself, 
though I am caching arrays of strings returned from the search results - but 
I don't imagine this creates references to $ldap.

To fix this for the time being, after getting the Connection Reset error I 
(i) call $ldap->unbind, and (ii) close $ldap->socket()

This seems to stop the file descriptor problem, but I am concerned that there 
may be a larger scale memory leak going on.

- Can anyone shed any light on this?
- Should there be some other method in perl-ldap that does a more thorough, 
explicit cleanup?

Many thanks,
Stephen Brandon
st...@br...

Re: Insecure dependency in perl-ldap 0.21+

[Ziya S. <zi...@ri...>]

On 2003-01-06 09:13:24 +0000, Chris Ridd wrote:
> On 6/1/03 8:40 am, Ziya Suzen <zi...@ri...> wrote:
> > Hi,
> > 
> > Thanks for the quick response.
> > 
> > [...]
> > 
> >> Is your patch still needed with the current version of perl-ldap - 0.26?
> > 
> > Yes.
> > 
> > Long answer is; Message.pm has remained the same since 'version 1.4,
> > 2000/09/12 09:17:09' looking at cvs. I guess we can say;
> > 
> > Patch is needed with any version of perl-ldap where
> > $Net::LDAP::Message::VERSION == 1.05
> > 
> > Cheers,
> > 
> > Ziya.
> > 
> > 
> 
> I was wondering if there was anything else in 0.26 which might have made the
> problem "go away" (I can't think how, but...) You're probably right about
> this affecting all subsequent versions, but it would still be good to check
> if the fix is actually needed in 0.26.

 Sorry for the confusion. Seems like the version I have been working
 on is '0.26'.

  $ perl -MNet::LDAP -le'print$Net::LDAP::VERSION'
  0.26

Thanks,

Ziya.

Re: Insecure dependency in perl-ldap 0.21+

[Chris R. <chr...@ma...>]

On 6/1/03 8:40 am, Ziya Suzen <zi...@ri...> wrote:
> Hi,
> 
> Thanks for the quick response.
> 
> [...]
> 
>> Is your patch still needed with the current version of perl-ldap - 0.26?
> 
> Yes.
> 
> Long answer is; Message.pm has remained the same since 'version 1.4,
> 2000/09/12 09:17:09' looking at cvs. I guess we can say;
> 
> Patch is needed with any version of perl-ldap where
> $Net::LDAP::Message::VERSION == 1.05
> 
> Cheers,
> 
> Ziya.
> 
> 

I was wondering if there was anything else in 0.26 which might have made the
problem "go away" (I can't think how, but...) You're probably right about
this affecting all subsequent versions, but it would still be good to check
if the fix is actually needed in 0.26.

Cheers,

Chris

Re: Insecure dependency in perl-ldap 0.21+

[Ziya S. <zi...@ri...>]

Hi,

Thanks for the quick response.

[...]

> Is your patch still needed with the current version of perl-ldap - 0.26?

  Yes.

  Long answer is; Message.pm has remained the same since 'version 1.4,
  2000/09/12 09:17:09' looking at cvs. I guess we can say;

  Patch is needed with any version of perl-ldap where
  $Net::LDAP::Message::VERSION == 1.05

Cheers,

Ziya.

Re: Insecure dependency in perl-ldap 0.21+

[Chris R. <chr...@ma...>]

On 5/1/03 10:36 pm, Ziya Suzen <zi...@ri...> wrote:

> (see http://sourceforge.net/mailarchive/message.php?msg_id=514287)
> 
> Hi,
> 
> I had the same problem:
> 
> Insecure dependency in require while running with -T switch
> at /usr/local/lib/perl5/site_perl/5.6.0/Net/LDAP/Message.pm line 86.
> 
> To me, it happened randomly, so I couldn't really trace down the
> error. But I managed to come up with kind of a test case and a patch
> for Message.pm.
> 
> Looks like Perl bug report #17867. Another thing: it happens with
> 5.6.0 not with 5.8.0. Looks like 5.8.0 treads server_error's return
> variable for Taint checks. But I am not sure if this will be the case
> on production code.
> 
> Any way the patch below is solving the problem at least for me. What
> do you think?

Is your patch still needed with the current version of perl-ldap - 0.26?

Cheers,

Chris

Insecure dependency in perl-ldap 0.21+

[Ziya S. <zi...@ri...>]

(see http://sourceforge.net/mailarchive/message.php?msg_id=514287)

Hi,

I had the same problem:

Insecure dependency in require while running with -T switch
at /usr/local/lib/perl5/site_perl/5.6.0/Net/LDAP/Message.pm line 86.

To me, it happened randomly, so I couldn't really trace down the
error. But I managed to come up with kind of a test case and a patch
for Message.pm.

Looks like Perl bug report #17867. Another thing: it happens with
5.6.0 not with 5.8.0. Looks like 5.8.0 treads server_error's return
variable for Taint checks. But I am not sure if this will be the case
on production code.

Any way the patch below is solving the problem at least for me. What
do you think?

Ziya Suzen
------------
RIPE NCC

try running this test with perl5.6.0 script you should get 'Insecure
dependency',(unless $msg->code =! 0)

Test case:
#/usr/bin/perl -T
use Net::LDAP;
$ld = new Net::LDAP('ldap.itd.umich.edu');
$msg = $ld->bind();
$msg->error();
print $msg->code(),"\n";

Patch for Message.pm:
--- /usr/local/lib/perl5/site_perl/5.6.0/Net/LDAP/Message.pm    Fri
Aug 24
21:24:09 2001
+++ blib/lib/Net/LDAP/Message.pm        Sat Jan  4 03:29:47 2003
@@ -83,9 +83,15 @@

 sub error {
   my $self = shift;
-  $self->server_error
-    or require Net::LDAP::Util
-    and Net::LDAP::Util::ldap_error_desc( $self->code );
+
+  my $return;
+
+  unless ($return = $self->server_error) {
+     require Net::LDAP::Util and
+     $return = Net::LDAP::Util::ldap_error_desc( $self->code );
+  }
+
+  $return;
 }

 sub set_error {

Re: NET::LDAP bind as NULL

[Gerald (J. C. <je...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 2 Jan 2003, Paul Harwood wrote:

> I am trying to bind to a Windows 2000 DC using the default credentials
> that I am logged on with. Using the LDP.exe tool I can do this by
> binding as "null" or the user that is currently logged in. Is there an
> easy way to do this use the NET::LDAP module?

>From UNIX, this works if you use the Authen::SASL::Cyrus module and the 
GSSAPI SASL mechanism.  Sounds like you are trying to run on Windows so my 
advice may be irrelevant.  Have you tried just using a SASL bind ?




cheers, jerry
 ----------------------------------------------------------------------
 Hewlett-Packard            ------------------------- http://www.hp.com
 GnuPG Key                  ---- http://www.plainjoe.org/gpg_public.asc
 ISBN 0-672-32269-2         "SAMS Teach Yourself Samba in 24 Hours" 2ed
 "You can never go home again, Oatman, but I guess you can shop there."  
                            --John Cusack - "Grosse Point Blank" (1997)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE+FJG/IR7qMdg1EfYRAqa0AJ0cu2ddU1mVso24hRQT2c9RTwYG3wCgzZQm
jxb/LpnrFOnZHkNtEV++pi4=
=QSMO
-----END PGP SIGNATURE-----

NET::LDAP bind as NULL

[Paul H. <ha...@ny...>]

I am trying to bind to a Windows 2000 DC using the default credentials
that I am logged on with. Using the LDP.exe tool I can do this by
binding as "null" or the user that is currently logged in. Is there an
easy way to do this use the NET::LDAP module?

-Paul

[Fwd] Net::LDAP::Schema name2oid

[Graham B. <gb...@po...>]

----- Forwarded message from Gary Lawrence Murphy <ga...@ca...> -----

Date: 02 Jan 2003 12:37:28 -0500
To: Graham Barr <gb...@po...>, John Berthels <jj...@ne...>
From: Gary Lawrence Murphy <ga...@ca...>
Subject: Net::LDAP::Schema name2oid


Sorry to bug you on this, but I'm trying to update the FSF oladm
LDAP admin program and I'm stuck on what looks like an old legacy
API call to a schema->name2oid(oc) call that is no longer in the
Schema API ... is there now some other way to obtain the oid?

-- 
Gary Lawrence Murphy - ga...@te... - TeleDynamics Communications
   - blog: http://www.teledyn.com/mt/ - biz: http://teledyn.com/ -
  "Computers are useless. They can only give you answers." (Picasso)

----- End forwarded message -----

Re: Re: Adding text attributes with international characters

[Pedro P. <pf...@ma...>]

> (...) that suggests two things:
> 
> 1) you're sending Latin-1 values for cn to the server, which is illegal;

 Yep, I was sending Latin1 characters :( .
 Converting to utf8 solved the problem.
 Thanx for your answer ...

--
Pedro Pires
-- 
Crie o seu email gratuito no mail.pt
http://www.mail.pt

Re: Net::LDAP Recursive Delete

[Graham B. <gb...@po...>]

On Sat, Dec 28, 2002 at 04:38:15PM +0000, Chris Ridd wrote:
> On 24/12/02 2:05 am, Eric Nichols <eri...@di...> wrote:
> > As far as I know the Net::LDAP::Entry does not do recursive deletes.
> > You'll need to write a recursive function.  If you need one let me know.
> > I've got one laying around here somewhere :)
> 
> Net::LDAP::Entry's got nothing to do with it - the LDAP protocol itself
> doesn't have recursive deletes. There may be some proprietary controls on
> some servers which permit it, but in general you'll have to write something
> yourself.

There was a tree delete control specified in a draft rfc that
expired. AD supports it, others may too.

  use Net::LDAP::Constants qw(LDAP_CONTROL_TREE_DELETE);

  $ldap->delete($dn_to_delete, control => { type => LDAP_CONTROL_TREE_DELETE });

Graham.

Re: Adding text attributes with international characters

[Chris R. <chr...@ma...>]

On 27/12/02 8:06 pm, Pedro Pires <pf...@ma...> wrote:

> Hi,
>=20
> I don't know if this is the proper place to ask this question, but here i=
t
> goes (if it's not could someone please direct me to a more suitable place=
?):
>=20
> How can I add a text attribute with international characters?

In LDAPv3 most "string" attributes are UTF-8 encoded Unicode strings. If
that meets your definition of "international", great :-) If not, you'll nee=
d
to convert your text into UTF-8 encoded Unicode. There are probably some
perl modules on CPAN which will help.

> If I do this:
>=20
> my $entry =3D Net::LDAP::Entry->new();
> $entry->dn("uid=3Dsomeone,ou=3Dwhatever,o=3Dblabla");
> $entry->add( 'uid' =3D> 'someone');
> $entry->add( 'cn' =3D> 'No wierd charaters');
> $entry->add( 'cn' =3D> 'With an international character: =E3 ...');
> $entry->add( 'cn;lang-pt' =3D> 'With another international character: =E1 ...=
');
> $entry->update($ldap);

Looks OK, except that entries *must* have an objectclass attribute set
correctly.

> I get the following result:
>=20
> dn: uid=3Dsomeone,ou=3Dwhatever,o=3Dblabla,
> uid: someone
> cn: No wierd charaters
> cn:: V2l0aCBhbiBpbnRlcm5hdGlvbmFsIGNoYXJhY3Rlcjog4yAuLi4=3D
> cn;lang-pt:: V2l0aCBhbm90aGVyIGludGVybmF0aW9uYWwgY2hhcmFjdGVyOiDhIC4uLg=3D=3D
>=20
> The last two 'cn' atributes are binary attributes and not text ones.

OK, what do you mean by "get" the following result? What program got this
result, and how did it decide to print it for you?

Assuming that the program is generating a proper LDIF file for you, then it
has basically printed two values for cn using base-64 encoding. Programs
that print LDIF usually base-64 encode certain values if they contain
characters that are "unsafe" in LDIF, eg non-ASCII characters (but there ar=
e
other cases too.)

If you decode those two base-64 strings (eg using
MIME::Base64::decode_base64), the first one contains an \xe3 character and
the second octal an \xe1 character. Both of those are Latin-1 encodings of
the two characters in your example, so that suggests two things:

1) you're sending Latin-1 values for cn to the server, which is illegal;

2) your server is not checking you're giving legal input and simply
returning whatever bytes you're giving it. Garbage In Garbage Out!

I'd strongly recommend you translate your input strings into UTF-8 encoded
Unicode and send those to the server instead. That way your script will wor=
k
when you upgrade your server.

Cheers,

Chris

Re: Net::LDAP Recursive Delete

[Chris R. <chr...@ma...>]

On 24/12/02 2:05 am, Eric Nichols <eri...@di...> wrote:
> As far as I know the Net::LDAP::Entry does not do recursive deletes.
> You'll need to write a recursive function.  If you need one let me know.
> I've got one laying around here somewhere :)

Net::LDAP::Entry's got nothing to do with it - the LDAP protocol itself
doesn't have recursive deletes. There may be some proprietary controls on
some servers which permit it, but in general you'll have to write something
yourself.

Cheers,

Chris

Adding text attributes with international characters

[Pedro P. <pf...@ma...>]

Hi,

 I don't know if this is the proper place to ask this question, but here it
goes (if it's not could someone please direct me to a more suitable place?):

 How can I add a text attribute with international characters?

 If I do this:

  my $entry = Net::LDAP::Entry->new();
  $entry->dn("uid=someone,ou=whatever,o=blabla");
  $entry->add( 'uid' => 'someone');
  $entry->add( 'cn' => 'No wierd charaters');
  $entry->add( 'cn' => 'With an international character: ã ...');
  $entry->add( 'cn;lang-pt' => 'With another international character: á ...');
  $entry->update($ldap);

I get the following result:

  dn: uid=someone,ou=whatever,o=blabla,
  uid: someone
  cn: No wierd charaters
  cn:: V2l0aCBhbiBpbnRlcm5hdGlvbmFsIGNoYXJhY3Rlcjog4yAuLi4=
  cn;lang-pt:: V2l0aCBhbm90aGVyIGludGVybmF0aW9uYWwgY2hhcmFjdGVyOiDhIC4uLg==

 The last two 'cn' atributes are binary attributes and not text ones.

--
Thank you in advance,
Pedro Pires
-- 
10Mb na sua caixa de email gratuita no mail.pt
http://www.mail.pt

Re: Searching for attributes in Win2k/Exchange 2000

[Eric N. <eri...@di...>]

You need to bind with a user account.  Unless you've done something 
special to your domain controller (access wise) an anonymous connection 
will only show the RootDSE object.

Perl wrote:
> I am trying to understand why this doesn't work. I am trying to list all
> attributes associated with the base search path. The problem is that
> nothing below CN=Services is ever displayed. I run the script and it
> returns nothing. I know the attributes are there as I can view them
> using LDP.EXE. If I modify the script to search CN=Services I see them
> just fine.  I have 2 questions:
> 
> 1) Anything below CN=Services does not return any attributes. Why? I can
> see them in LDP but can't get them to print using this script.
> 2) Is there a preferred method to getting attributes in this manner?
> 
> Ultimately what I am trying to do is populate a list of Exchange 2000
> servers that exist in the organization. I want to do a recursive search
> under: "CN=Administrative Groups,CN=MYTESTDOMAIN,CN=Microsoft
> Exchange,CN=Services,CN=Configuration,DC=mynetwork,DC=com" but I can't
> seem to get any attributes to show. 
> 
> Any help very appreciated.
> 
> --Paul
> 
> 
> ----
> 
> 
> use Net::LDAP qw(:all);                    
> 
>        use Net::LDAP::Util qw(ldap_error_name       
>                               ldap_error_text) ;    
>                               
> $ldap = Net::LDAP->new("newyork",port => '3268') or die "$@";
> 
> $ldap->bind;         # use for searches
> 
> my $result = $ldap->search (
>                     base    => "CN=Microsoft
> Exchange,CN=Services,CN=Configuration,DC=mynetwork,DC=com",
>                     scope   => "sub",
>                     filter  => '(objectclass=*)',
>                     attrs => ['*']
>                     );
>   
>   
>          my @entries = $result->entries;
> 
> 
>         my $entr ;
>         foreach $entr ( @entries )
>            {
>             print "DN: ",$entr->dn,"\n";
>             #my @attrs = sort $entr->attributes;
> 
> 
>             my $attr;
>            foreach $attr ( sort $entr->attributes ){
>                 #skip binary we can't handle
>                 next if ( $attr =~ /;binary$/ );
>                 print "  $attr : ",$entr->get_value($attr),"\n";
>                 }
> 
> 
>             #print "@attrs\n";
>                 print "#-------------------------------\n";
>            }
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> 
> 

Searching for attributes in Win2k/Exchange 2000

[Perl <Pe...@ny...>]

I am trying to understand why this doesn't work. I am trying to list all
attributes associated with the base search path. The problem is that
nothing below CN=3DServices is ever displayed. I run the script and it
returns nothing. I know the attributes are there as I can view them
using LDP.EXE. If I modify the script to search CN=3DServices I see them
just fine.  I have 2 questions:

1) Anything below CN=3DServices does not return any attributes. Why? I =
can
see them in LDP but can't get them to print using this script.
2) Is there a preferred method to getting attributes in this manner?

Ultimately what I am trying to do is populate a list of Exchange 2000
servers that exist in the organization. I want to do a recursive search
under: "CN=3DAdministrative Groups,CN=3DMYTESTDOMAIN,CN=3DMicrosoft
Exchange,CN=3DServices,CN=3DConfiguration,DC=3Dmynetwork,DC=3Dcom" but I =
can't
seem to get any attributes to show.=20

Any help very appreciated.

--Paul


----


use Net::LDAP qw(:all);                   =20

       use Net::LDAP::Util qw(ldap_error_name      =20
                              ldap_error_text) ;   =20
                             =20
$ldap =3D Net::LDAP->new("newyork",port =3D> '3268') or die "$@";

$ldap->bind;         # use for searches

my $result =3D $ldap->search (
                    base    =3D> "CN=3DMicrosoft
Exchange,CN=3DServices,CN=3DConfiguration,DC=3Dmynetwork,DC=3Dcom",
                    scope   =3D> "sub",
                    filter  =3D> '(objectclass=3D*)',
                    attrs =3D> ['*']
                    );
 =20
 =20
         my @entries =3D $result->entries;


        my $entr ;
        foreach $entr ( @entries )
           {
            print "DN: ",$entr->dn,"\n";
            #my @attrs =3D sort $entr->attributes;


            my $attr;
           foreach $attr ( sort $entr->attributes ){
                #skip binary we can't handle
                next if ( $attr =3D~ /;binary$/ );
                print "  $attr : ",$entr->get_value($attr),"\n";
                }


            #print "@attrs\n";
                print "#-------------------------------\n";
           }

using perl-ldap with win2k active directory

[<ka...@bg...>]

hellow all,
I need to use web Authentication via web pages 
against active directory . I have IIS and Apache web servers with ASP , PHP and Oracle IAS .
How Can I use perl-ldap (a sample code ) to get the
username and passrod via a web page and check it in activeDirectory

Thanks
dror


Dror Litan
Oracle DBA system ,Computation Center
Ben-Gurion University


Dror Litan
Oracle DBA system ,Computation Center
Ben-Gurion University

using perl ldap with win2k active directory

[<ka...@bg...>]

hellow all,
I need to use web Authentication via web pages 
against active directory . I have IIS and Apache web servers with ASP , PHP and Oracle IAS .
How Can I use perl-ldap (a sample code ) to get the
username and passrod via a web page and check it in activeDirectory

Thanks
dror


Dror Litan
Oracle DBA system ,Computation Center
Ben-Gurion University