perl-ldap-dev

Re: [Fwd] Problem with Net::LDAP

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

Graham Barr <gb...@po...> wrote:
> It is taking so much memory because it is reading all the results into
> memory before returning for you to process them.
> 
> I suspect you don't really need all of the entries, so try modifying your
> filter to result the resutl set that is being sent.
> 
> If this is not possible, try using the callback option. This allows you
> to process each entry as it arrives from the server.
> 
> Graham.

This is true, however 95000 * 200 bytes (rough size of the example entry)
only comes to about 18 megabytes, and Simon said his perl process was using
250 megabytes :-(

That's a lot of overhead, unless Simon missed a zero out of his entry count
- 950000 entries would work out to use about the observed quantity of
memory. Well, the same order of magnitude anyway.

Cheers,

Chris

Re: [Fwd] Problem with Net::LDAP

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

It is taking so much memory because it is reading all the results into
memory before returning for you to process them.

I suspect you don't really need all of the entries, so try modifying your
filter to result the resutl set that is being sent.

If this is not possible, try using the callback option. This allows you
to process each entry as it arrives from the server.

Graham.

On Tue, May 29, 2001 at 09:41:54AM +0100, Graham Barr wrote:
> ----- Forwarded message from Simon Allard <sim...@st...> -----
> 
> Date: Tue, 29 May 2001 17:51:59 +1200 (NZST)
> To: <gb...@po...>
> From: Simon Allard <sim...@st...>
> Subject: Problem with Net::LDAP
> 
> Hey Graham.
> 
> I am hopeing you can shed some light on this. I have this problem where
> your module seems to chew up a lot of memory.
> 
> I am running openldap 2.0.7 with perl-ldap-0.23.
> 
> In openldap I have Aprox 95000 entrys. Each entry looks similar to this:
> 
> dn:loginName=dbs, ou=auth, dc=domain, dc=co, dc=nz
> objectclass: AuthAccount
> loginName: dbs
> userPassword: {crypt}sgaCZydxWDFD
> nasAccess: SOMETHING
> smtpAuth: 0
> overrideProfile: 1
> multicast: 0
> 
> When I do a basic search eg:
> 
> if (!$ldap->bind("cn=Manager, $authbase", password => $authpass, async => 1)) {
> 	print "Ldap Bind failed!\n";
> 	exit 1;
> }
> my $mesg = $ldap->search(
>         base => "$authbase",
>         filter => '(objectclass=ihugAuthAccount)'
>        );
> 
> $ldap->unbind;
> 
> This search seems to chew up over 250meg of Ram. It pretty much makes the
> perl module unusable. Do you have any suggestions on how I could get the
> memory usage down to something reasonable?
> 
> Also doing the unbind seems to take a very long time :(
> 
> Hope you can help.
> Thanks in Advance.
> 
> Regards
> Simon Allard
> 
> 
> 
> Simon Allard (Senior Tool Monkey)
> IHUG
> Ph (09) 358-5067   Email: sim...@st...
> 
> The real fighting men and women of the 21st century will continue
> to be techo's backed up by the grunts with bad haircuts and rifles.
> 
> 
> ----- End forwarded message -----

[Fwd] Problem with Net::LDAP

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

----- Forwarded message from Simon Allard <sim...@st...> -----

Date: Tue, 29 May 2001 17:51:59 +1200 (NZST)
To: <gb...@po...>
From: Simon Allard <sim...@st...>
Subject: Problem with Net::LDAP

Hey Graham.

I am hopeing you can shed some light on this. I have this problem where
your module seems to chew up a lot of memory.

I am running openldap 2.0.7 with perl-ldap-0.23.

In openldap I have Aprox 95000 entrys. Each entry looks similar to this:

dn:loginName=dbs, ou=auth, dc=domain, dc=co, dc=nz
objectclass: AuthAccount
loginName: dbs
userPassword: {crypt}sgaCZydxWDFD
nasAccess: SOMETHING
smtpAuth: 0
overrideProfile: 1
multicast: 0

When I do a basic search eg:

if (!$ldap->bind("cn=Manager, $authbase", password => $authpass, async => 1)) {
	print "Ldap Bind failed!\n";
	exit 1;
}
my $mesg = $ldap->search(
        base => "$authbase",
        filter => '(objectclass=ihugAuthAccount)'
       );

$ldap->unbind;

This search seems to chew up over 250meg of Ram. It pretty much makes the
perl module unusable. Do you have any suggestions on how I could get the
memory usage down to something reasonable?

Also doing the unbind seems to take a very long time :(

Hope you can help.
Thanks in Advance.

Regards
Simon Allard



Simon Allard (Senior Tool Monkey)
IHUG
Ph (09) 358-5067   Email: sim...@st...

The real fighting men and women of the 21st century will continue
to be techo's backed up by the grunts with bad haircuts and rifles.


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

Re: Need help with Paging

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

Did you really have

    my($resp)  = $mesg->control( LDAP_CONTROL_PAGED ) or last;

or did you have

    my $resp   = $mesg->control( LDAP_CONTROL_PAGED ) or last;

Note that there are no ()' in the second example

Graham.

On Thu, May 24, 2001 at 12:18:56PM -0400, Eric Nichols wrote:
> I'm trying to use Net::LDAP::Control::Paged with ActiveDirectory.  I checked
> the DSA record and it supports paging:
> supportedControl: 1.2.840.113556.1.4.319
> 
> I used the example exactly and it worked.  On a whim I dialed the page size
> back to 5 and ran it again.  I found that I only got 5 objects.  The issue
> seems to be in the lines:
>    # Get cookie from paged control
>    my($resp)  = $mesg->control( LDAP_CONTROL_PAGED ) or last;
>    $cookie    = $resp->cookie or last;
> 
> For some reason $resp dosen't get assigned.  I did a dump using
> Data::Dumper - print Dumper($msg->control)
> I got:
> $VAR1 = bless( {
>                  'value' => '0c00 c ',
>                  'type' => '1.2.840.113556.1.4.319'
>                }, 'Net::LDAP::Control::Paged' );
> 
> When I ran Dumper on $mesg->control( LDAP_CONTROL_PAGED ) I got:
> $VAR1 = 1;
> 
> Obviously the data is in the control part but I can't seem to get it out
> correctly.  Any assistance would be greatly appreciated!
> 
> 
> 

Need help with Paging

[Eric N. <eni...@cp...>]

I'm trying to use Net::LDAP::Control::Paged with ActiveDirectory.  I checked
the DSA record and it supports paging:
supportedControl: 1.2.840.113556.1.4.319

I used the example exactly and it worked.  On a whim I dialed the page size
back to 5 and ran it again.  I found that I only got 5 objects.  The issue
seems to be in the lines:
   # Get cookie from paged control
   my($resp)  = $mesg->control( LDAP_CONTROL_PAGED ) or last;
   $cookie    = $resp->cookie or last;

For some reason $resp dosen't get assigned.  I did a dump using
Data::Dumper - print Dumper($msg->control)
I got:
$VAR1 = bless( {
                 'value' => '0♣☻☺ ♦ ',
                 'type' => '1.2.840.113556.1.4.319'
               }, 'Net::LDAP::Control::Paged' );

When I ran Dumper on $mesg->control( LDAP_CONTROL_PAGED ) I got:
$VAR1 = 1;

Obviously the data is in the control part but I can't seem to get it out
correctly.  Any assistance would be greatly appreciated!

Re: Perl Journal write up

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

On Thu, May 24, 2001 at 09:06:03AM -0500, Clif Harden wrote:
> 
> The latest issue of the Perl Journal has a write up about LDAP that
> uses the Perl LDAP module.
> 
> We probably can expect more questions about Netscapes PerLDAP module.
> 
> The author in the resources section called the Perl LDAP module PerLDAP
> and referenced the Perl LDAP web page at sourceforge.

Hehe I love that. I really shows they know thier stuff :)

Graham.

Perl Journal write up

[Clif H. <cl...@di...>]

The latest issue of the Perl Journal has a write up about LDAP that
uses the Perl LDAP module.

We probably can expect more questions about Netscapes PerLDAP module.

The author in the resources section called the Perl LDAP module PerLDAP
and referenced the Perl LDAP web page at sourceforge.

Regards,

Clif 

Re: Possible bug in ->objectclasses()

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

On Wed, May 23, 2001 at 08:03:23AM -0500, Clif Harden wrote:
> > 
> > 
> > 
> > Please try the attached patch.
> > 
> > This changes the name2oid method to return all oids for a given name.
> > Also some methods will now return undef if the name passed maps to
> > more than one oid.
> 
> 
> Returning undef is okay IF you are going to provide a 
> error function that explains why the method returned
> undef.

Yes, error handling is something that needs to be added thought the whole module

Graham.

Re: Possible bug in ->objectclasses()

[Clif H. <cl...@di...>]

> 
> 
> 
> Please try the attached patch.
> 
> This changes the name2oid method to return all oids for a given name.
> Also some methods will now return undef if the name passed maps to
> more than one oid.


Returning undef is okay IF you are going to provide a 
error function that explains why the method returned
undef.

Clif




> 
> Graham.
> 
> On Wed, May 23, 2001 at 08:22:01AM +0100, Graham Barr wrote:
> > On Tue, May 22, 2001 at 08:35:09PM -0400, Steve Neruda wrote:
> > > I am writing some scripts to make sure that several Netscape Director
> > > Servers are configured the same.  Part of the process is to make sure
> > > that they have the same objectclasses, attributres, matching rules, and
> > > syntaxes.  While writing the object class part I may have encountered a
> > > bug.  There is both an attribute and object class named "locality" in
> > > the netscape directory server:
> > > 
> > > 
> > > neruda@farmer:config> sudo grep -i locality slapd.*.conf
> > > slapd.at.conf:attribute l   locality              
> > > localityname             2.5.4.7                    cis     
> > > slapd.oc.conf:objectclass locality
> > > 
> > > Now if I run this test script below I would expect to see only object
> > > classes printed out put instead 'locality' shows up as an attribute:
> > 
> > > Am I doing something wrong here?
> > 
> > No you are not.
> > 
> > I have just looked at the code and it does make the assumption that
> > no two items will have the same name. The API for name2oid will
> > need to be changed so that when requestion something you either
> > pass the type you are looking for or get a list of all of them.
> > 
> > Graham.
> > > 
> > > 
> 

Re: setting acl's via perl-ldap ?

[Gael LE N. <gle...@if...>]

 hello
it is possible,
this is syntaxe for Netscape directory serveur

my $aci =3D '(target=3D"ldap:///-DN-")(targetattr=3D"-nom attr-")(version=
 3.0;
acl "-nom acl-"; deny(all) userdn =3D "ldap:///self";)' ;

$ldap->modify($dn_modif, add =3D> {'aci' =3D> $aci });


Stefan Poschenrieder a =E9crit :
>=20
> Hello,
>=20
> is it possible to create acl's via perl-ldap ?

--=20
Ga=EBl LE NERRIEC
Stagiaire IFREMER	TMSI/IDM/RIC
____________________________________________
El=E8ve ing=E9nieur IRESTE
Ecole Polytechnique de l'universit=E9 de Nantes
D=E9partement Syst=E8mes Informatiques Logiciels et R=E9seaux

setting acl's via perl-ldap ?

[Stefan P. <st...@ra...>]

Hello,

is it possible to create acl's via perl-ldap ?

my first try was to create an entry with attribute aci=<any acl>...
but i got an LDAP_INVALID_SYNTAX error..

cheers,
stefan

Re: Possible bug in ->objectclasses()

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

Please try the attached patch.

This changes the name2oid method to return all oids for a given name.
Also some methods will now return undef if the name passed maps to
more than one oid.

Graham.

On Wed, May 23, 2001 at 08:22:01AM +0100, Graham Barr wrote:
> On Tue, May 22, 2001 at 08:35:09PM -0400, Steve Neruda wrote:
> > I am writing some scripts to make sure that several Netscape Director
> > Servers are configured the same.  Part of the process is to make sure
> > that they have the same objectclasses, attributres, matching rules, and
> > syntaxes.  While writing the object class part I may have encountered a
> > bug.  There is both an attribute and object class named "locality" in
> > the netscape directory server:
> > 
> > 
> > neruda@farmer:config> sudo grep -i locality slapd.*.conf
> > slapd.at.conf:attribute l   locality              
> > localityname             2.5.4.7                    cis     
> > slapd.oc.conf:objectclass locality
> > 
> > Now if I run this test script below I would expect to see only object
> > classes printed out put instead 'locality' shows up as an attribute:
> 
> > Am I doing something wrong here?
> 
> No you are not.
> 
> I have just looked at the code and it does make the assumption that
> no two items will have the same name. The API for name2oid will
> need to be changed so that when requestion something you either
> pass the type you are looking for or get a list of all of them.
> 
> Graham.
> > 
> > 

Re: Retrieving a specific DN

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

Christoph Neumann <en...@ap...> wrote:
> Brian,
> 
> That is the "official" way to retrieve a specific DN.  What I have never
> understood is why I needed to specify a filter if I'm doing a
> "base" search.  I'm sure there is some good explanation for that.

Well, all searches *require* filters, so that's one (sort of) reason.
Another reason is you may need to be able to ask does an entry match some
expression eg (&(userid=cjr)(telephoneNumber=999)). You can't do that using
other operations like compare.

Life would perhaps be simpler if LDAP had a read operation like DAP, but
remember the L in LDAP stands for Lightweight :-) and unfortunately that
means the application must work a bit harder to compensate :-(

Cheers,

Chris

Re: Possible bug in ->objectclasses()

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

On Tue, May 22, 2001 at 08:35:09PM -0400, Steve Neruda wrote:
> I am writing some scripts to make sure that several Netscape Director
> Servers are configured the same.  Part of the process is to make sure
> that they have the same objectclasses, attributres, matching rules, and
> syntaxes.  While writing the object class part I may have encountered a
> bug.  There is both an attribute and object class named "locality" in
> the netscape directory server:
> 
> 
> neruda@farmer:config> sudo grep -i locality slapd.*.conf
> slapd.at.conf:attribute l   locality              
> localityname             2.5.4.7                    cis     
> slapd.oc.conf:objectclass locality
> 
> Now if I run this test script below I would expect to see only object
> classes printed out put instead 'locality' shows up as an attribute:

> Am I doing something wrong here?

No you are not.

I have just looked at the code and it does make the assumption that
no two items will have the same name. The API for name2oid will
need to be changed so that when requestion something you either
pass the type you are looking for or get a list of all of them.

Graham.
> 
> 

Possible bug in ->objectclasses()

[Steve N. <ne...@na...>]

I am writing some scripts to make sure that several Netscape Director
Servers are configured the same.  Part of the process is to make sure
that they have the same objectclasses, attributres, matching rules, and
syntaxes.  While writing the object class part I may have encountered a
bug.  There is both an attribute and object class named "locality" in
the netscape directory server:


neruda@farmer:config> sudo grep -i locality slapd.*.conf
slapd.at.conf:attribute l   locality              
localityname             2.5.4.7                    cis     
slapd.oc.conf:objectclass locality

Now if I run this test script below I would expect to see only object
classes printed out put instead 'locality' shows up as an attribute:


#!/usr/bin/perl 
use Net::LDAP;
use Net::LDAP::LDIF;
use Net::LDAP::Schema;

$host1="localhost";
$port1="3389";

my $ldap1 = Net::LDAP->new($host1,dn=>'cn=Directory
Manager',password=>'c00kie$4mango',port=>"$port1")
  || die "couldn't connect to $host1 on port $port1" ;

$ldap1->bind();
$schema1 = $ldap1->schema();
die "Get schema1  failed" unless $schema1;

@objs= $schema1->objectclasses;
foreach $oc (@objs) {
  if ($schema1->is_objectclass($oc)) {
    print "OBJECTCLASS: $oc\n";
    @must = $schema1->must($oc);
    @may = $schema1->may($oc);
  } else {
    print "attribute: $oc" if $schema1->is_attribute($oc);
    print "is_syntax: $oc" if $schema1->is_syntax($oc);
    print "is_matchingrule: $oc" if $schema1->is_matchingrule($oc);
    print "\n\n";
  }
  print
"----------------------------------------------------------------\n"
}

Output:

OBJECTCLASS: TOP
----------------------------------------------------------------
OBJECTCLASS: ALIAS
----------------------------------------------------------------
OBJECTCLASS: COUNTRY
----------------------------------------------------------------
attribute: LOCALITY


Am I doing something wrong here?

Re: Retrieving a specific DN

[Christoph N. <en...@ap...>]

Brian,

That is the "official" way to retrieve a specific DN.  What I have never
understood is why I needed to specify a filter if I'm doing a
"base" search.  I'm sure there is some good explanation for that.

- Christoph


On Tue, 22 May 2001, Brian Safford wrote:

> The only way I've found I can retrieve an entry if the only thing I know is the distinguished name is as follows:
> 
> $dn = 'cn=last name,ou=messaging,o=eds,c=us';
> 
> $result = $ldap->search( base   => $dn,
>                          scope  => 'base',
>                          filter => '(objectclass=*)',
>                          callback => \&Display,
>                      );
> 
> I can substitute other attributes for 'objectclass' provided a value exists.
> 
> Is there any other way?  Seems like it should be easier than this, but perhaps this isn't really that difficult...
> 
> Regards,
> 
> Brian Safford
> Consultant, Senior
> Perimeter Messaging
> EDS E.solutions Messaging Services
> 

Retrieving a specific DN

[Brian S. <bri...@ed...>]

The only way I've found I can retrieve an entry if the only thing I know =
is the distinguished name is as follows:

$dn =3D 'cn=3Dlast name,ou=3Dmessaging,o=3Deds,c=3Dus';

$result =3D $ldap->search( base   =3D> $dn,
                         scope  =3D> 'base',
                         filter =3D> '(objectclass=3D*)',
                         callback =3D> \&Display,
                     );

I can substitute other attributes for 'objectclass' provided a value =
exists.

Is there any other way?  Seems like it should be easier than this, but =
perhaps this isn't really that difficult...

Regards,

Brian Safford
Consultant, Senior
Perimeter Messaging
EDS E.solutions Messaging Services

perl-ldap´Ô ¾È³çÇϼ¼¿ä?

[¿Â¶óÀÎÄÚ¸®¾Æ<ol...@ol...>]

PEhUTUw+DQo8SEVBRD4NCjxNRVRBIE5BTUU9IkdFTkVSQVRPUiIgQ29udGVudD0iTWljcm9z
b2Z0IERIVE1MIEVkaXRpbmcgQ29udHJvbCI+DQo8VElUTEU+PC9USVRMRT4NCjwvSEVBRD4N
CjxCT0RZPg0KPFA+PEZPTlQgY29sb3I9IzAwODAwMCBmYWNlPbG8uLLDvCBzaXplPTI+osQg
v8C0w8DHIMCvuNMgosU8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0y
PjxGT05UIGNvbG9yPSMwMDAwODA+oeGw+r3Dv+U8QlI+PC9GT05UPkEgZ2lybCBnb3QgYW4g
DQplbmdhZ2VtZW50IHJpbmcsIGFuZCB3b3VsZCBzZWl6ZSBldmVyeSBvcHBvcnR1bml0eSBm
b3IgPEJSPmNhbGxpbmcgYXR0ZW50aW9uIHRvIA0KaXQuJm5ic3A7IDxCUj5JbiBhIGdyb3Vw
IHdpdGggZ2lybCBmcmllbmRzIG5vIG9uZSBub3RpY2VkIGl0LiZuYnNwOyBGaW5hbGx5IHdo
ZW4gDQpoZXI8QlI+ZnJpZW5kcyB3ZXJlIHNpdHRpbmcgYXJvdW5kIHRhbGtpbmcsIHNoZSBn
b3QgdXAgc3VkZGVubHkgYW5kIHNhaWQsIA0KPEJSPiJJdCdzIGF3ZnVsbHkgaG90IGluIGhl
cmUuIEkgdGhpbmsgSSdsbCB0YWtlIG15IHJpbmcgb2ZmLiI8L0ZPTlQ+PC9QPg0KPFA+PEZP
TlQgZmFjZT2xvLiyw7wgc2l6ZT0yPqHec2VpemUgZXZlcnkgb3Bwb3J0dW5pdHkgZm9yIH4g
aW5nIDogseLIuLi4IMDWwLi46SB+IA0Kx8+02S48QlI+od5jYWxsIGF0dGVudGlvbiB0byA6
IH4gv6EgwdbAx7imIMivseK9w8WwtNkuIDxCUj6h3mF3ZnVsbHkgOiB2ZXJ5IDwvRk9OVD48
L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+vuDIpbndwfa4piC53sC6IL7GsKG+
vrTCILHiyLi4uCDA1sC4uOkgu+e297Xpv6Gw1CCx1yC53cH2uKYguri/qcHWt8Gw7SZuYnNw
OyANCjxCUj616b76tNkmbmJzcDsgPEJSPsfRufjAuiC/qcDaxKOxuLXpsPogvu6/77fItMK1
pSC+xrmrtbUgsdcgud3B9rimILSrv6mw3CC6wcHWwfYgvsq+0rTZPEJSPri2xKezuyC+xrCh
vr60wiC02bXpILXRt6++yb7GIA0KwMy+37HiuKYgs6q0qbDtIMDWtMIgxse/oSC5+raxIMDP
vu68rbjpvK0gPEJSPri7x9+02S48QlI+Ir7uyN4sILT1v/a8rSC4+CCw37XwsNqz1y4gs6og
ud3B9rimILupvt8gx9Kx7rrBISImbmJzcDsgDQo8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgY29s
b3I9IzAwODAwMCBmYWNlPbG8uLLDvCBzaXplPTI+osQgv8C0w8DHIL+1vu4gx9G4trXwIKLF
PC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj48Rk9OVCBjb2xvcj0j
MDAwMDgwPqLDILCou+fAxyC4u8C7IMfSILanPC9GT05UPjxCUj6/3LG5wM616cC6ILOyv6Gw
1CC+xsHWIA0KwNvAuiC1tb/ywLsgud6+xrW1ICJUaGFuayB5b3UuKLCou+fH1bTPtNkuKSK2
87DtIDxCUj64u8fYv+QuIMDMsM3AuiC+7rfIwLsgtqe6zsXNILHXt7EgsbPAsMC7ILnewLi4
6bytIMDatvMgv9Sx4iC2p7muv6EguPa/oSANCjxCUj66o77uIMDWvu4gu/O067nmwMcgu+e8
0sfRILW1v/LAzLOqIMSjwP2/obW1ICJUaGFuayB5b3UuIrbzsO0guLvHz7TCIL3AsPw8QlI+
wLsgsK6w1CC1yLDFILCwvsa/5C4gubC30Cwgv+y4rrW1IA0KuLbC+bChwfbB9ri4v+QuPEJS
PiJUaGFuayB5b3UuIr+hILTrx9EgwMC05MC6ICLDtbi4v6G/5C4itvO0wiC25sC4t84gIllv
dSBhcmUgd2VsY29tZS4gLzxCUj5Eb24ndCANCm1lbnRpb24gaXQuIC9Ob3QgYXQgYWxsLiK1
7sDHIMelx/bAuyC+ssHSLiA8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6
ZT0yPkE6IEl0IHdhcyB2ZXJ5IGtpbmQgb2YgeW91IHRvIGdvIHRvIHRoYXQgdHJvdWJsZSBm
b3IgDQptZS48QlI+QjogSXQgd2FzIG5vIHRyb3VibGUgYXQgYWxsLiBJdCB3YXMgbXkgcGxl
YXN1cmUuPEJSPkE6IEl0J3MgdmVyeSBraW5kIG9mIA0KeW91IHRvIHNheSBzby48QlI+Jm5i
c3A7PEJSPkE6IMD6uKYgwKfH2LytILHXt7EgvPaw7bimIMfYIMHWvcO0zyDBpLi7ILDtuL+9
wLTPtNkuPEJSPkI6ILm5ILz2sO229iCwzcDMIMDWs6q/5C4gDQrBprChIMHBvsa8rSDH0SDA
z8DOtaW/5C48QlI+QTogsde3uLDUILi7vrjH2CDB1r3DtM8gwaS4uyCw7bi/vcC0z7TZLjxC
Uj4mbmJzcDs8QlI+PEZPTlQgY29sb3I9IzAwMDA4MD6h4bCou+fAxyANCrHiursgx6XH9jxC
Uj48L0ZPTlQ+osIgVGhhbmsgeW91LiAvVGhhbmtzLjxCUj4mbmJzcDsmbmJzcDsgormwqLvn
x9W0z7TZLjxCUj6iwiBUaGFua3MgYSBsb3QuIA0KL1RoYW5rIHlvdSB2ZXJ5IG11Y2guIC9U
aGFuayB5b3Ugc28gbXVjaC48QlI+Jm5ic3A7Jm5ic3A7IKK5tOu03Mj3ILCou+fH1bTPtNku
PEJSPqLCIEknZCANCmFwcHJlY2lhdGUgaXQuPEJSPiZuYnNwOyZuYnNwOyCiubHXt7iw1CDH
2CDB1r3DuOkgsKi758fPsNq9wLTPtNkuPEJSPqLCIEkgYXBwcmVjaWF0ZSBpdCB2ZXJ5IA0K
bXVjaC48QlI+Jm5ic3A7Jm5ic3A7IKK5sdcgwaEgwaS4uyCwqLvnx9W0z7TZLjxCUj6iwiBP
biBiZWhhbGYgb2Ygb3VyIGVtcGxveWVlcyBJJ2QgbGlrZSB0byANCnRoYW5rIHlvdS48QlI+
Jm5ic3A7Jm5ic3A7IKK5wPrI8SDIuLvnv/i16cC7ILTrx6XH2LytILTnvcW/obDUILCou+cg
teW4rrDtIL3NvcC0z7TZLjxCUj4mbmJzcDs8QlI+PEZPTlQgDQpjb2xvcj0jMDA4MDAwPqLE
IMDfuPggvrLAzyC89iDA1rTCIMelx/YgosU8QlI+Jm5ic3A7PEJSPjwvRk9OVD48Rk9OVCBj
b2xvcj0jMDAwMDgwPqLDIL+pseK8rSANCjHIo7yxwLi3ziCwpb7Gxbi8xb7fIMfVtM+02TxC
Uj4mbmJzcDs8QlI+PC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDA+oeFZb3UgaGF2ZSB0byBz
aGlmdCB0byANCnRoZSBOby4xIExpbmUuoeuh66Hroeuh66Hroeuh66Hroeuh66HtKFgpPEJS
PjwvRk9OVD48Rk9OVCBjb2xvcj0jMDA4MDgwPqHhWW91J2xsIGhhdmUgdG8gDQp0cmFuc2Zl
ciB0byB0aGUgTm8uMSBMaW5lIGZyb20gaGVyZS6h66Hroeuh7ShPKTxCUj4mbmJzcDs8QlI+
PC9GT05UPqLBc2hpZnS0wiC067CzILDFwdbB9rOqIA0Ku/2wosC7ILnZstu02bTCILbmwMy5
x7fOIL+pseK8rbTCILjCwfYgvsq+xr/kLiA8QlI+Jm5ic3A7ILGzxevG7cC7ILClvsbFuLTC
ILDNwLogurjF6yB0cmFuc2ZlcrbzsO0gx9i/5C4gsde4rrDtILPrvLHAuyANCrClvsbFuLTC
IDxCUj4mbmJzcDsgyK+9wr+qtbUgdHJhbnNmZXK287DtIMfPtMK1pSwgwMy2p7TCILjtu+fA
1LTPtNkuIDxCUj4mbmJzcDsguvHH4LHiIL+px+Agwd+/oSCwpb7Gxbi0wiCx4sL4wfa0wiAN
CnN0b3BvdmVytvOw7SDH2L/kLjxCUj4mbmJzcDs8QlI+od5Ob3cgeW91IGhhdmUgdG8gc3dp
dGNoIHRvIHRoZSBOby4xIExpbmUuKL+pseK8rSAxyKO8scC4t84gDQqwpb7Gxbi8vL/kLik8
QlI+od5Zb3UgaGF2ZSB0byBnZXQgb3ZlciB0byB0aGUgTm8uMSBMaW5lLigxyKO8sSDCysC4
t84gsKG8xbytIMW4vLy/5C4pPC9GT05UPjwvUD4NCjxQPjxGT05UIGNvbG9yPSMwMDgwMDAg
ZmFjZT2xvLiyw7wgc2l6ZT0yPqLEIL/AtMPAxyDAz77uIMfRuLa18CCixTwvRk9OVD48L1A+
DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+osLAz7q7vu61tSC/tb7uv80gsLDAuiDH
/MXCt84gsbi8urXHvu4gDQrA1r3AtM+02S48QlI+oeuh66Hroeuh66Hroeuh66Hroeuh66Hr
oeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh66Hroeuh6zxCUj5wZXJs
LWxkYXC01CC+yLPnx8+8vL/kPyA8L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wg
c2l6ZT0yPsD6yPG0wiDA/MituKYgwMy/68fYvK0gsK2757/NIDEgOiAxILfOIL/csbm+7iDH
0L3AwLsgx9IgvPYgwNa0wiA8QlI+PEEgDQpocmVmPSJodHRwOi8vd3d3Lm9say5jby5rciI+
osQgT25saW5lIEtvcmVhIKLFIDwvQT6287DtIMfVtM+02S48QlI+ucy4riDH47b0ud7B9iC+
yrDtIMbtwfYgteW3wSANCsHLvNvH1bTPtNkuILrOtfAgs8qx17evv+y9xSC/67ytuKYuLi4u
Li48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPsD6yPEgyLi757+h
vK20wiC/3LG5vu4ov7W+7izAz77uKb+hILD8vckgwNa0wiC4ucC6ILrQtemysiC4xcDPKL/5
LbHdKSwgPEJSPr+1vu7Ar7jTv80gDQq7/ciwv6Egx8q/5MfRIMi4yK0gx9Egua7A5b6/wLsg
uau34bfOILq4s7sgteW4rrDtIMDWvu6/5C48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT2x
vLiyw7wgc2l6ZT0yPsCnv80gsLDAuiCzu7/rwMcgvK268b26uKYgud6+xrq4seIgv/jHz73D
uOkgoewgPEEgDQpocmVmPSJtYWlsdG86b2xrQG9say5jby5rciI+b2xrQG9say5jby5rcjwv
QT4goe23ziA8QlI+PEZPTlQgDQpjb2xvcj0jZmYwMDAwPiJ5ZXMiPC9GT05UPrbztMIgs7u/
68DHILTkwOXAuyDB1r3DseIgudm2+LTPtNkuIDwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNl
PbG8uLLDvCBzaXplPTI+sde4rrDtLCDA+sjxIMD8yK0gv9yxub7uILCtwMewoSCxw7Hdx8+9
xSC60LXpwLsgwKfH2CwgMci4v6Egx9HH2LytPEJSPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5v
bGsuY28ua3IvaW5zdGlfZnJhbWUuaHRtIj6iwiC5q7fhIL3DufywrcDHIKLCPC9BPrW1IL3H
vcPH2CC15biusO0gwNbAuLTPIMfRufggtem+7rq4sO0gDQq9zcC4vcO46SA8QlI+wfax3SC9
xcO7x9ggwda8vL/kLjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+
uau34SC9w7n8sK3AxyC9xcO7ILnmuf3AuiA8QSANCmhyZWY9Imh0dHA6Ly93d3cub2xrLmNv
LmtyL2luc3RpX2ZyYW1lLmh0bSI+orogwMyw9yCiuCA8L0E+wLsgxay4r8fPvcUgyMQgsK3A
xyC9xcO7tvW/oSANCsDWtMI8QlI+vcO5/LCtwMcgvcXDuyDG+8C7IMDbvLrHz7zFvK0guriz
uyDB1r3DuOkgtcu0z7TZLjxCUj65sLfQLCDA/MitIDxGT05UIGNvbG9yPSMwMDgwMDA+MDIt
NTg4LTA1MTAgDQo8L0ZPTlQ+wLi3zrW1IL3Fw7vHz73HILz2IMDWsbi/5C48L0ZPTlQ+PC9Q
Pg0KPFA+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPr7GuavCybfPIMDMIMfQvcC5/cDMIHBl
cmwtbGRhcLTUwMcgyLjIrSC9x7fCIMfiu/O/oSDA28C6ILq4xcbAzCA8QlI+tce++sC4uOkg
DQrH1bTPtNkuPC9GT05UPjwvUD4NCjxQPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj5wZXJs
LWxkYXC01LKytMIgaHR0cDovL2NvbXAubWFpbHgyLmNvbTo4MC9wZXJsZG9jcy9zaXRlL2xp
Yi9OZXQvTERBUC9GQVEuaHRtbL+hIMDWtMIgwda80rimILq4sO0guN7AzyC15bfItMK1pb/k
LDxCUj660sfKv+TH0SANCsGkuri/tLTZuOkgwaS4uyDBy7zbx9W0z7TZLjxCUj6+1cC4t84g
x+O29L74tMIguN7Az8C6ILXluK7B9iC+yrW1t88gx8+w2r3AtM+02S48QlI+sde3sywgvsiz
58j3IA0KsOi8vL/kLjwvRk9OVD48L1A+DQo8L0JPRFk+DQo8L0hUTUw+DQo=

Re: The Perl Conference

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

Firstly I would like to thanks all those who responded with
suggestions.

I am in the process of finishing these off as they have to be in
tomorrow. I think I have all the content, just a few formatting
things to fixup.

Anyway I have recreated the slides at
   http://monty.mutatus.co.uk/~gbarr/TPC/img0.htm

If anyone wants to make any last minute suggestions feel free.

You will notice that the schema section is small. I did this because
I don't feel comfortable with describing schemas. Maybe if I learn
between now and the conf I will add some supplemental slides.

Anyway if anyone on this list is at the conference, be sure to come
and say Hi.

Again, Thanks for all the feedback.
Graham.

Re: [Fwd] Dear Mr. Barr : ldap problem

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

Graham Barr <gb...@po...> wrote:
> Can anyone on this list help Mrvka ? I don't actually have
> an example of using Convert::ASN1 to encode/decode a
> certificate
> 
> Graham.
> 
> ----- Forwarded message from Mrvka Andreas <mr...@tu...> -----
> 
> Date: Thu, 17 May 2001 10:07:35 +0200
> To: "'gb...@po...'" <gb...@po...>
> From: Mrvka Andreas <mr...@tu...>
> Subject: Dear Mr. Barr : ldap problem
> X-Mailer: Internet Mail Service (5.5.2650.10)
> 
> Dear Mr. Barr,
> 
> I've found your perl-ldap module and use it in my company.
> It's working fine! 
> 
> Now I have to check out a binary data for certificates and found your
> tool Convert-ASN1.
> 
> it seems that this tool does what I need but it's a little bit too less
> documented how I can work with it.
> 
> Will you please be so kind and mail me an example for encoding/decoding
> a certificate (binary data)?
> 
> Just if it's no problem.
> 
> Thanks for your help!
> 
> best regards
> 
> Mrvka Andreas
> 
> --------------------------------------------------------------------
> MRVKA Andreas 
> TUEV AUSTRIA                            Tel.: +43 1 / 514 07 - 6050
> IT - Group                              Fax : +43 1 / 514 07 - 6005
> A-1015 Vienna, Krugerstrasse 16         email: mr...@tu...
> AUSTRIA                                 web : www.tuev.at
> --------------------------------------------------------------------
> 
> ----- End forwarded message -----
> 

You don't say what you want to extract from your certificates... Here is
some code which decodes a cert, and has a minimal DN decoder too. It prints
out the validity period and subject and issuer DNs, just as an example.

Cheers,

Chris

[Fwd] Dear Mr. Barr : ldap problem

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

Can anyone on this list help Mrvka ? I don't actually have
an example of using Convert::ASN1 to encode/decode a
certificate

Graham.

----- Forwarded message from Mrvka Andreas <mr...@tu...> -----

Date: Thu, 17 May 2001 10:07:35 +0200
To: "'gb...@po...'" <gb...@po...>
From: Mrvka Andreas <mr...@tu...>
Subject: Dear Mr. Barr : ldap problem
X-Mailer: Internet Mail Service (5.5.2650.10)

Dear Mr. Barr,

I've found your perl-ldap module and use it in my company.
It's working fine! 

Now I have to check out a binary data for certificates and found your
tool Convert-ASN1.

it seems that this tool does what I need but it's a little bit too less
documented how I can work with it.

Will you please be so kind and mail me an example for encoding/decoding
a certificate (binary data)?

Just if it's no problem.

Thanks for your help!

best regards

Mrvka Andreas

--------------------------------------------------------------------
MRVKA Andreas 
TUEV AUSTRIA                            Tel.: +43 1 / 514 07 - 6050
IT - Group                              Fax : +43 1 / 514 07 - 6005
A-1015 Vienna, Krugerstrasse 16         email: mr...@tu...
AUSTRIA                                 web : www.tuev.at
--------------------------------------------------------------------

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

Re: FW: Net::LDAP::LDIF

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

On Tue, May 15, 2001 at 10:32:29AM -0700, Robbie Allen wrote:
> Attached is a final patch to LDIF.pm and a patch for LDIF.pod

Excellent, Thanks.

I will apply this tonight

Graham.

[Fwd] OpenLDAP , PerLdap and UTF 8

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

----- Forwarded message from tom...@em... -----

Date: Tue, 15 May 2001 19:37:21 +0200
To: gb...@po...
From: tom...@em...
Subject: OpenLDAP , PerLdap and UTF 8
X-mailer: Pegasus Mail for Win32 (v3.12c)

Hi !

I had some problems with users DN/CN containing German=20
"Umlaute" like =FC=F6=E4=D6=C4=DC=DF, every bind failed. Finding no reall=
y=20
helpfull comments in the docs, faqs, mailing lists i finally found a=20
solution at least for me.
The points here are=20
-> ldap v3 uses utf8, ldap v2 t61 .Perldap uses v2 as standard.
-> perl 5.6 does support utf8 but the data coming in is probably=20
something like latin1.

So after half a day :

# Pragma to use UTF 8
    use utf8;
# convert out gotten username from latin1 to utf8
    $user =3D~ tr/\0-\xff//CU;

    my $ldap =3D Net::LDAP->new('server',port =3D> "389") or return=20
(undef, "$@")  ;

# Binding with version 3 so utf8 is the encoding the server expects
    my $result =3D $ldap->bind ( =20
              dn       =3D> "$user",
              password =3D> "$passwd",
              version =3D> '3'
             );

I dont know if there is a more elegant solution, but the way should=20
be documented somewhere, so other ppl have a chance without=20
going into change files,faqs,docs and mailing lists from=20
perl,openldap and perldap.

greetings and thanx for your module
	tom bille

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

Re: The Perl Conference

[Daniel B. <da...@un...>]

Hi Graham,

I just glimpsed over your slides and found some typos:

A typo on slide 13, second item in the enumeration: it should be Equipment
instead of  Equiptment.

And on slide 28 you speak of a method called get_value but in the code a
mathod get is used ... hmmmm, something wrong in the state of Denmark ;-) ?

On slide 41 there's a double 'the' on the third topic.

A small typo on slide 55: end of 2nd topic says 'in this fields', should be
singular.

A small typo on slide 56: end of 3rd subtopic: says 'for then given error',
should be 'for the ...'.

Typo on slide 57, first topic: 'not a simple as' should be 'not as simple
as'.

Typo on slide 57, 2nd topic, 5th subtopic: 'and traing spaces' should be
'and trailing spaces'

That's all I have found so far (some slides are not filled with content yet,
as you have mentioned).
Apart from the typos, I think these are good slides. And a lot of them, too
:-). Wow, 62 slides! How long is your course supposed to be?
Hope this helps.

Keep up the good work,
Daniel.

----- Original Message -----
From: Graham Barr <gb...@po...>
To: LDAP Mailing List <per...@li...>
Sent: Monday, May 14, 2001 12:21 PM
Subject: The Perl Conference


> As many already know I will be giving a tutorial on Net::LDAP at the perl
> conference this year.
>
> However here is your chnace at a sneak preview and hopefully give me
> some feednack. The slides I have done so far are at
>
>   http://monty.mutatus.co.uk/~gbarr/TPC/img0.htm
>
> I am still writing the slides, but I am running out of time fast.
>
> Any feeback is most welcome.
>
> After the conference I will place the complete set of slides on the
perl-ldap
> website
>
> Graham.
>

RE: FW: Net::LDAP::LDIF

[Robbie A. <ra...@ci...>]

Attached is a final patch to LDIF.pm and a patch for LDIF.pod

Robbe Allen

> -----Original Message-----
> From: Graham Barr [mailto:gb...@po...]
> Sent: Saturday, May 12, 2001 12:34 AM
> To: Robbie Allen
> Cc: per...@li...
> Subject: Re: FW: Net::LDAP::LDIF
> 
> 
> On Fri, May 11, 2001 at 05:39:22PM -0700, Robbie Allen wrote:
> 
> > If the changes are acceptable, I'll also modify LDIF.pod to 
> include the new
> > syntax along with write_entry() examples.
> 
> Looks good to me, except the default for onerror should be undef IMO.
> 
> Excellent, Thanks,
> Graham.
>