You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(200) |
Jun
(129) |
Jul
(184) |
Aug
(204) |
Sep
(106) |
Oct
(79) |
Nov
(72) |
Dec
(54) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(83) |
Feb
(123) |
Mar
(84) |
Apr
(184) |
May
(106) |
Jun
(111) |
Jul
(104) |
Aug
(91) |
Sep
(59) |
Oct
(99) |
Nov
(100) |
Dec
(37) |
2002 |
Jan
(148) |
Feb
(88) |
Mar
(85) |
Apr
(151) |
May
(80) |
Jun
(110) |
Jul
(85) |
Aug
(43) |
Sep
(64) |
Oct
(89) |
Nov
(59) |
Dec
(42) |
2003 |
Jan
(129) |
Feb
(104) |
Mar
(162) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Graham B. <gb...@po...> - 2001-09-21 17:13:16
|
Ah, I think I see the problem. There is a problem with decoding structures like SEQUENCE OF SEQUENCE OF Foo This may take sometime to fix as it changes a fundamental assumption of the code. Graham. On Fri, Sep 21, 2001 at 01:50:00PM +0100, Graham Barr wrote: > Hm, odd. >=20 > Can you send me a file you are trying to decode and the script > you are using. >=20 > Graham. >=20 > On Fri, Sep 21, 2001 at 09:47:40AM +0200, Norbert Klasen wrote: > > Hi, > > I'm trying to decode X.509 certificates with Convert::ASN1 (0.14). This= =20 > > works quite well exept for Names: > >=20 > > AttributeTypeAndValue ::=3D SEQUENCE { > > type AttributeType, > > value AttributeValue } > >=20 > > RelativeDistinguishedName ::=3D SET OF AttributeTypeAndValue > >=20 > > RDNSequence ::=3D SEQUENCE OF RelativeDistinguishedName > >=20 > > Name ::=3D CHOICE { -- only one possibility for now -- > > rdnSequence RDNSequence } > >=20 > >=20 > > It seems, as if the hashs for the SET elements are added to the wrong= =20 > > parent. As result I get something like: > >=20 > > issuer =3D> { > > rdnSequence =3D> [], > > value =3D> '=16=1Ac...@tr...', > > type =3D> '1.2.840.113549.1.9.1' > > } > >=20 > > --=20 > > Norbert Klasen > > DAASI International GmbH phone: +49 7071 29 70336 > > Wilhelmstr. 106 fax: +49 7071 29 5114 > > 72074 T=FCbingen email: norbert.klasen@daasi.= de > > Germany web: http://www.daasi.de > >=20 > >=20 > >=20 |
From: Graham B. <gb...@po...> - 2001-09-21 12:51:20
|
Hm, odd. Can you send me a file you are trying to decode and the script you are using. Graham. On Fri, Sep 21, 2001 at 09:47:40AM +0200, Norbert Klasen wrote: > Hi, > I'm trying to decode X.509 certificates with Convert::ASN1 (0.14). This= =20 > works quite well exept for Names: >=20 > AttributeTypeAndValue ::=3D SEQUENCE { > type AttributeType, > value AttributeValue } >=20 > RelativeDistinguishedName ::=3D SET OF AttributeTypeAndValue >=20 > RDNSequence ::=3D SEQUENCE OF RelativeDistinguishedName >=20 > Name ::=3D CHOICE { -- only one possibility for now -- > rdnSequence RDNSequence } >=20 >=20 > It seems, as if the hashs for the SET elements are added to the wrong=20 > parent. As result I get something like: >=20 > issuer =3D> { > rdnSequence =3D> [], > value =3D> '=16=1Ac...@tr...', > type =3D> '1.2.840.113549.1.9.1' > } >=20 > --=20 > Norbert Klasen > DAASI International GmbH phone: +49 7071 29 70336 > Wilhelmstr. 106 fax: +49 7071 29 5114 > 72074 T=FCbingen email: nor...@da... > Germany web: http://www.daasi.de >=20 >=20 >=20 |
From: Chris R. <chr...@me...> - 2001-09-21 08:44:12
|
Norbert Klasen <nor...@da...> wrote: > Hi, > I'm trying to decode X.509 certificates with Convert::ASN1 (0.14). This > works quite well exept for Names: > > AttributeTypeAndValue ::= SEQUENCE { > type AttributeType, > value AttributeValue } > > RelativeDistinguishedName ::= SET OF AttributeTypeAndValue > > RDNSequence ::= SEQUENCE OF RelativeDistinguishedName > > Name ::= CHOICE { -- only one possibility for now -- > rdnSequence RDNSequence } > > > It seems, as if the hashs for the SET elements are added to the wrong > parent. As result I get something like: > > issuer => { > rdnSequence => [], > value => '??cer...@tr...', > type => '1.2.840.113549.1.9.1' > } I tend to leave the DNs in the basic certificate as 'ANY', and then decode them separately. my %oid2attr = ( '2.5.4.3' => 'cn', '2.5.4.6' => 'c', '2.5.4.7' => 'l', '2.5.4.8' => 'st', '2.5.4.10' => 'o', '2.5.4.11' => 'ou', '0.9.2342.19200300.100.1.25' => 'dc' ); $asn->prepare(q< SEQUENCE { SEQUENCE { [0] IMPLICIT SEQUENCE { version INTEGER } serialNumber ANY, -- an INTEGER, but potentially big sigalg ANY, issuer ANY, -- a DN SEQUENCE { notBefore UTCTime, notAfter UTCTime } subject ANY, -- a DN spkinfo ANY, issueruid [1] IMPLICIT ANY OPTIONAL, subjectuid [2] IMPLICIT ANY OPTIONAL, [3] IMPLICIT SEQUENCE { extensions ANY } } alg ANY OPTIONAL, sig BIT STRING }>) or die; my $out = $asn->decode($cert) or die; print decodeDN($out->{'subject'}); sub decodeDN { my $pdu = shift; my $dn = Convert::ASN1->new; $dn->prepare("rdns SEQUENCE OF ANY"); my $rdn = Convert::ASN1->new; $rdn->prepare("rdn SET OF ANY"); my $ava = Convert::ASN1->new; $ava->prepare(q< SEQUENCE { type OBJECT IDENTIFIER, CHOICE { p PrintableString, t T61String, b BMPString, u UniversalString, i IA5String } } >); my $rdns = $dn->decode($pdu); my @dn; foreach my $a (@{$rdns->{rdns}}) { my $b = $rdn->decode($a); my @rdn; foreach my $c (@{$b->{rdn}}) { my $d = $ava->decode($c); my $s = $oid2attr{$d->{type}}; my $v = $d->{p} || $d->{t} || $d->{b} || $d->{u} || $d->{i} || die "Not a recognized syntax!"; $v =~ s/([+,=\\\$])/sprintf("\\%02X", ord($1))/eg; push @rdn, "$s=$v"; } unshift @dn, join("+", @rdn); } return join(", ", @dn); } This won't work for all attributes and syntaxes, but it should be OK for the commonly used ones. Cheers, Chris |
From: Norbert K. <nor...@da...> - 2001-09-21 07:47:14
|
Hi, I'm trying to decode X.509 certificates with Convert::ASN1 (0.14). This=20 works quite well exept for Names: AttributeTypeAndValue ::=3D SEQUENCE { type AttributeType, value AttributeValue } RelativeDistinguishedName ::=3D SET OF AttributeTypeAndValue RDNSequence ::=3D SEQUENCE OF RelativeDistinguishedName Name ::=3D CHOICE { -- only one possibility for now -- rdnSequence RDNSequence } It seems, as if the hashs for the SET elements are added to the wrong=20 parent. As result I get something like: issuer =3D> { rdnSequence =3D> [], value =3D> '=16=1Ac...@tr...', type =3D> '1.2.840.113549.1.9.1' } --=20 Norbert Klasen DAASI International GmbH phone: +49 7071 29 70336 Wilhelmstr. 106 fax: +49 7071 29 5114 72074 T=FCbingen email: nor...@da... Germany web: http://www.daasi.de |
From: Soeeberg, P. <ps...@fi...> - 2001-09-20 20:45:13
|
Hi Christopher, Thanks for replying as swift as you did. I found that I had trouble understanding the login procedure on the active directory ldap server. ... I just have one single question left, which I hope you (or someone else) would help me with. Please do note that I'm rather new at this ldap thingy (And perl for that sake) You wrote: >> Might want to check result codes here to make sure your bind is successful. I always give bind an explicit DN to bind as... How do I find the result code? Is it common for all types of object calls? Regards, Philip S. -----Original Message----- From: Christopher A Bongaarts [mailto:ca...@tc...]=20 Sent: 20. september 2001 19:11 To: Soeeberg, Philip Cc: per...@li... Subject: Re: LDAP Search error (Win2K AD) As Soeeberg, Philip once put it so eloquently: > I have this annoying problem when trying to search my Active Directory > Server, and I have no idea what's causing it. >=20 > The text returned is: > 0000020D6: SvcErr: DSID-03100690, problem 5012 (DIR_ERROR), data 0 Couple ideas: > $ldap->bind(version=3D>3,password=3D>'password'); Might want to check result codes here to make sure your bind is successful. I always give bind an explicit DN to bind as... > $mesg =3D $ldap->search ( # perform a search > base =3D> "c=3DDK", > filter =3D> "(&(sn=3DTest) (o=3Dmy test = company))" > ); I suspect you might really want: $mesg =3D $ldap->search (base =3D> "o=3Dmy test company, c=3DDK", filter =3D> "sn=3DTest"); %% Christopher A. Bongaarts %% ca...@tc... %% %% Internet Services %% http://umn.edu/~cab %% %% University of Minnesota %% +1 (612) 625-1809 %% |
From: Christopher A B. <ca...@tc...> - 2001-09-20 17:11:29
|
As Soeeberg, Philip once put it so eloquently: > I have this annoying problem when trying to search my Active Directory > Server, and I have no idea what's causing it. > > The text returned is: > 0000020D6: SvcErr: DSID-03100690, problem 5012 (DIR_ERROR), data 0 Couple ideas: > $ldap->bind(version=>3,password=>'password'); Might want to check result codes here to make sure your bind is successful. I always give bind an explicit DN to bind as... > $mesg = $ldap->search ( # perform a search > base => "c=DK", > filter => "(&(sn=Test) (o=my test company))" > ); I suspect you might really want: $mesg = $ldap->search (base => "o=my test company, c=DK", filter => "sn=Test"); %% Christopher A. Bongaarts %% ca...@tc... %% %% Internet Services %% http://umn.edu/~cab %% %% University of Minnesota %% +1 (612) 625-1809 %% |
From: Soeeberg, P. <ps...@fi...> - 2001-09-20 16:37:24
|
Hi; I have this annoying problem when trying to search my Active Directory Server, and I have no idea what's causing it. The text returned is: 0000020D6: SvcErr: DSID-03100690, problem 5012 (DIR_ERROR), data 0 This is my code: ---[SNIP]--- use Net::LDAP qw(:all); use Net::LDAP::Util qw(ldap_error_name); print "Creating new LDAP..."; $ldap =3D Net::LDAP->new('192.168.1.1') or die print "$@"; $ldap->bind(version=3D>3,password=3D>'password'); $mesg =3D $ldap->search ( # perform a search base =3D> "c=3DDK", filter =3D> "(&(sn=3DTest) (o=3Dmy test = company))" ); =20 $mesg->code && print $mesg->error; foreach $entry ($mesg->all_entries) { $entry->dump; } =20 $ldap->unbind; # take down session 1; ---[/SNIP]--- Can someone reconise this error, and if possible help a newbie like me? Hope to hear from someone, Philip Soeeberg |
From: Chris R. <chr...@me...> - 2001-09-18 08:25:06
|
Graham Barr <gb...@po...> wrote: > ----- Forwarded message from "Ballard, Jerry" <Jer...@Sc...> > ----- > > Date: Mon, 17 Sep 2001 15:43:48 -0700 > To: "'gb...@po...'" <gb...@po...> > From: "Ballard, Jerry" <Jer...@Sc...> > Subject: replace method of 'modify' in perl-ldap > X-Mailer: Internet Mail Service (5.5.2448.0) > > Graham... > Given a multi-valued attribute, is it possible to remove a specific value > via perl-ldap? Yes, but not using the "replace" version of the modify operation (as per your subject) - that is defined by the LDAP standards to replace the *entire* attribute - which as you say is not always the most efficient thing to do. > example: > > cn: billy bob smith > cn: william robert smith > cn: da man > cn: bill smith > > I want to remove "da man" without touching the other 3. > > In PerLDAP (from Netscape), you would do it as follows: > $entry->removeValue("cn", "da man"); $ldap->modify('cn=my user,o=my org,c=US', delete => { 'cn' => 'da man' }); It used to be necessary to make the value a reference to a list, ie: $ldap->modify('cn=my user,o=my org,c=US', delete => { 'cn' => [ 'da man' ] }); The Net::LDAP man page has some more examples. Cheers, Chris |
From: Chris R. <chr...@me...> - 2001-09-18 08:15:06
|
Juan Posada <max...@ho...> wrote: > Hello, > Need some help with this problem.... > I am trying to authenticate users using LDAP and binding to a directory. > When I bind the password is sent in clear text. So I tried to bind > sending the password {SHA} encoded didn't work. I then tried to search > the directory and retrieve the password attribute to compare it with what > I got from the user but it does not get returned, then I am binding as > directory manager and that too is sent clear text so it really doesn't > solve my problem. > > Is there away to encrypt communications (or at least the password) > between the LDAP server and the other box without using SSL. I read Technically yes - if you authenticate using some SASL mechanisms you can negotiate a "confidential" connection. However I don't think that the Authen::SASL modules currently support that. Of course using SASL binds over a 'plain' LDAP connection is also pretty secure as the credentials are not conveyed on the network in the clear. Is it possible to use SASL? > about start_STLS, but I found it a bit vague and confusing. The start_tls method uses TLS, which is the standardized (RFCed) version of SSL (it contains a slightly different set of encryption algorithms and is slightly improved to avoid a few security problems, if I recall.) It shouldn't be too difficult to use - basically something like this: $ldap = Net::LDAP->new('hostname', version => 3); $ldap->start_tls(); # Now the connection is encrypted $ldap->bind('cn=my user,o=my org,c=WW', password => 'secret'); There are more things that you *should* do (but don't have to) after calling start_tls(), like checking the server's certificate is valid, and checking that the encryption algorithm being used is good. Is there a reason you can't use SSL or TLS? Cheers, Chris |
From: Graham B. <gb...@po...> - 2001-09-17 22:53:58
|
----- Forwarded message from "Ballard, Jerry" <Jer...@Sc...> ----- Date: Mon, 17 Sep 2001 15:43:48 -0700 To: "'gb...@po...'" <gb...@po...> From: "Ballard, Jerry" <Jer...@Sc...> Subject: replace method of 'modify' in perl-ldap X-Mailer: Internet Mail Service (5.5.2448.0) Graham... Given a multi-valued attribute, is it possible to remove a specific value via perl-ldap? example: cn: billy bob smith cn: william robert smith cn: da man cn: bill smith I want to remove "da man" without touching the other 3. In PerLDAP (from Netscape), you would do it as follows: $entry->removeValue("cn", "da man"); This is a very useful technique when dealing with large groups consisting of DNs because having to blow out the entire attribute and completely replacing it causes severe thrashing because of the need to update referential integrety for all those objects. thanks jerry ballard Charles Schwab & Co Inc ----- End forwarded message ----- |
From: Juan P. <max...@ho...> - 2001-09-17 19:05:37
|
Hello, Need some help with this problem.... I am trying to authenticate users using LDAP and binding to a directory. When I bind the password is sent in clear text. So I tried to bind sending the password {SHA} encoded didn't work. I then tried to search the directory and retrieve the password attribute to compare it with what I got from the user but it does not get returned, then I am binding as directory manager and that too is sent clear text so it really doesn't solve my problem. Is there away to encrypt communications (or at least the password) between the LDAP server and the other box without using SSL. I read about start_STLS, but I found it a bit vague and confusing. Thank you everyone, Juan _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp |
From: Juan P. <max...@ho...> - 2001-09-17 19:01:05
|
Hello, Need some help with this problem.... I am trying to authenticate users using LDAP and binding to a directory. When I bind the password is sent in clear text. So I tried to bind sending the password {SHA} encoded didn't work. I then tried to search the directory and retrieve the password attribute to compare it with what I got from the user but it does not get returned, then I am binding as directory manager and that too is sent clear text so it really doesn't solve my problem. Is there away to encrypt communications (or at least the password) between the LDAP server and the other box without using SSL. I read about start_STLS, but I found it a bit vague and confusing. Thank you everyone, Juan _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp |
From: Bob G. <go...@at...> - 2001-09-15 02:06:50
|
John -- my @vals = $entry -> get_value("mailacceptinggeneralid"); get_value() called in scalar context returns the first vale of a multi-valued attribute; called in array context yields all values. Bob G > Today's Topics: > > 1. multiple attributes, same name? (John Madden) > > --__--__-- > > Message: 1 > From: John Madden <jm...@iv...> > Organization: Ivy Tech State College > To: per...@li... > Subject: multiple attributes, same name? > Date: Fri, 14 Sep 2001 13:53:44 -0500 > > Perhaps that's not the best way of describing it, but let's say I've got an > entry that contains entries like this: > > maildrop: account > mailacceptinggeneralid: alias1 > mailacceptinggeneralid: alias2 > > This can be accomplished easily with $ldap->add by simply specifying two > mailacceptinggeneralid attributes. However, how does one go about retrieving > them? > > $entry->get_value("mailacceptinggeneralid") only returns the first of the two > entries. > > Thanks, > John > > -- > John Madden > UNIX Systems Engineer > Ivy Tech State College > jm...@iv... > > --__--__-- > > _______________________________________________ > perl-ldap-dev mailing list > per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-ldap-dev > > End of perl-ldap-dev Digest -- Bob Goolsby go...@at... The only thing with more energy than a puppy with a bone is a puppy with *two* bones. |
From: John M. <jm...@iv...> - 2001-09-14 19:17:05
|
> Call it in list context: > > get_value ( ATTR [, OPTIONS ] ) > Get the values for the attribute ATTR. In a list context > returns all values for the given attribute, or the empty > list if the attribute does not exist. In a scalar > context returns the first value for the attribute or > undef if the attribute does not exist. Ahh, that's the piece I was looking for. Thanks. John -- John Madden UNIX Systems Engineer Ivy Tech State College jm...@iv... |
From: Christopher A B. <ca...@tc...> - 2001-09-14 19:11:41
|
As John Madden once put it so eloquently: > mailacceptinggeneralid: alias1 > mailacceptinggeneralid: alias2 > > This can be accomplished easily with $ldap->add by simply specifying two > mailacceptinggeneralid attributes. However, how does one go about retrieving > them? > > $entry->get_value("mailacceptinggeneralid") only returns the first of the two > entries. Call it in list context: get_value ( ATTR [, OPTIONS ] ) Get the values for the attribute ATTR. In a list context returns all values for the given attribute, or the empty list if the attribute does not exist. In a scalar context returns the first value for the attribute or undef if the attribute does not exist. %% Christopher A. Bongaarts %% ca...@tc... %% %% Internet Services %% http://umn.edu/~cab %% %% University of Minnesota %% +1 (612) 625-1809 %% |
From: chad r. w. <cw...@vi...> - 2001-09-14 19:08:12
|
john try this: John Madden wrote: > > Perhaps that's not the best way of describing it, but let's say I've got an > entry that contains entries like this: > > maildrop: account > mailacceptinggeneralid: alias1 > mailacceptinggeneralid: alias2 > > This can be accomplished easily with $ldap->add by simply specifying two > mailacceptinggeneralid attributes. However, how does one go about retrieving > them? > > $entry->get_value("mailacceptinggeneralid") only returns the first of the two > entries. my $alias_ids = $entry->get_value("mailacceptinggeneralid", asref=>1); enjoy, chad -- chad r. west virage inc. software engineer 177 bovet road, suite 520 cw...@vi... san mateo, ca 94402 http://www.virage.com/ |
From: John M. <jm...@iv...> - 2001-09-14 18:57:07
|
Perhaps that's not the best way of describing it, but let's say I've got an entry that contains entries like this: maildrop: account mailacceptinggeneralid: alias1 mailacceptinggeneralid: alias2 This can be accomplished easily with $ldap->add by simply specifying two mailacceptinggeneralid attributes. However, how does one go about retrieving them? $entry->get_value("mailacceptinggeneralid") only returns the first of the two entries. Thanks, John -- John Madden UNIX Systems Engineer Ivy Tech State College jm...@iv... |
From: <rg...@di...> - 2001-09-13 18:46:34
|
Hi Chuck. My code is slightly different from yours in that I know the new value to be added and the old value to be deleted. I use a foreach loop on one array to obtain a string to compare against the other array with a 'grep' call then store the value to add or delete. foreach my $s (@arr ) { if ( grep /$s/,@owners ) { push @arr1,$s ; } } where @arr is the values being passed to change, @owners are the original values, and @arr1 is the set of values I'm going to pass the LDAP modify. Note: I just check for values being @arr1 to determine whether to make the modify or not. Hopefully, you can derive a proceedure to meet you needs. Rusty On Sep 13, 10:06am, Chuck Phillips wrote: > Subject: Handling attributes with multiple values. > I'm trying to incorporate the handling of mutivalued attributes > into my perl scripts and it's getting really messy. I'd like > to see some examples of what others have done to address this. > > For instance I might have a user with multiple titles: > > dn:uid=chuckp,ou=People,o=University of New Mexico,c=US > > objectclass: top > person > organizationalPerson > inetOrgPerson > sn: Phillips > givenname: Charles > mail: ch...@un... > uid: chuckp > title: Unix Administrator > LDAP Administrator > > Now In a feed I get the same user who now has 3 titles: > > chuckp:title:Unix Administrator,LDAP Administrator,Calendar Administrator: > > The problem is I want to be able to compare what I have in the new feed to > what is in LDAP and only update if I have to. Has anybody done something > similar? > > > > > Chuck Phillips > ch...@un... > <+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+> > > >-- End of excerpt from Chuck Phillips -- Russell Biggs (Rusty) Internet: r-...@ti... 6500 Chase Oaks Blvd, M/S 8412 Texas Instruments Plano Tx 75023 Phone: (972) 575-0826 Fax: (972) 575-4853 Home Page: http://dirtest3.itg.ti.com/~rgb Calendar: http://dirtest3.itg.ti.com/cgi-bin/synchronize.cgi?name=Russell+Biggs |
From: Chris F. <cf...@vi...> - 2001-09-13 17:41:47
|
On Thu, 13 Sep 2001 10:06:11 -0600 Chuck Phillips wrote: +------------------ | | The problem is I want to be able to compare what I have in the new feed to | what is in LDAP and only update if I have to. Has anybody done something | similar? | +------------------ The normal Perl solution to unique lists is to use a hash in some way. Maybe putting the attribute_values as keys in a hash where the value is some kind of action code? The Net::LDAP::Entry::update method is crucial to making this kind of thing work well. Fetch the entry from the directory, load it's attributes into few convenient hashes, process the changes into the hashes, run through them to add, replace and delete attributes in the the entry, then update it. Good luck chris -- |
From: Chuck P. <ch...@un...> - 2001-09-13 16:06:10
|
I'm trying to incorporate the handling of mutivalued attributes into my perl scripts and it's getting really messy. I'd like to see some examples of what others have done to address this. For instance I might have a user with multiple titles: dn:uid=chuckp,ou=People,o=University of New Mexico,c=US objectclass: top person organizationalPerson inetOrgPerson sn: Phillips givenname: Charles mail: ch...@un... uid: chuckp title: Unix Administrator LDAP Administrator Now In a feed I get the same user who now has 3 titles: chuckp:title:Unix Administrator,LDAP Administrator,Calendar Administrator: The problem is I want to be able to compare what I have in the new feed to what is in LDAP and only update if I have to. Has anybody done something similar? Chuck Phillips ch...@un... <+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+> |
From: <rv...@rv...> - 2001-09-13 15:13:02
|
Ob/5ILzSvcTB9iAgICcpIGkrKzsgaWYgKGkgJykgaSsrOyB9IGRlc3QgKz0gc3JjLnN1YnN0 cmluZyhtYXJrLCBpKTsgaWYgKGkgPj0gc3JjLmxlbmd0aCkgYnJlYWs7IGRlc3QgKz0gJyc7 IG1hcmsgPSBpOyB3aGlsZSAoaSAnOyB3b3JkaSsrOyB9IGVsLmlubmVySFRNTCA9IGRlc3Q7 IGVsLnBvc0xlZnQgPSAwOyBlbC5zdHlsZS52aXNpYmlsaXR5ID0gJ3Zpc2libGUnOyBsaXN0 W2luZGV4XSA9IG5hbW9zd19uZXdfYW5pbWF0aW9uX29iamVjdChlbC5uYW1lKyd3b3JkMScs IGVsLnN0YXJ0Q29uZE9iaiwgZWwuc3RhcnRDb25kVGltZSwgZWwuc3RhcnRYUG9zLCBlbC5z dGFydFlQb3MsIGVsLnBhdGhUeXBlLCBmYWxzZSwgZWwuem9vbSwgZWwuc3RlcE51bSk7IGZv ciAoaSA9IDE7IGkgMCkgeyBlbC5jb3VudERvd24gPSAoMCAwID8gLTE6MSkpOyBjb3N2ID0g TWF0aC5jb3MoTWF0aC5QSSplbC5zdGVwL2VsLnN0ZXBOdW0pOyBuZXd4ID0gKChjb3N2Kihl bC5zeC14KSAtIHNpbnYqKGVsLnN5LXkpICsgeCkgKyBsaW5leCkgLyAyOyBuZXd5ID0gKChz aW52KihlbC5zeC14KSArIGNvc3YqKGVsLnN5LXkpICsgeSkgKyBsaW5leSkgLyAyOyB9IGVs c2UgaWYgKGVsLnBhdGhUeXBlID09ICdzcGlyYWwnKSB7IHNpbnYgPSBNYXRoLnNpbigyKk1h dGguUEkqZWwuc3RlcC9lbC5zdGVwTnVtKTsgY29zdiA9IE1hdGguY29zKDIqTWF0aC5QSSpl bC5zdGVwL2VsLnN0ZXBOdW0pOyByID0gKGVsLnN0ZXBOdW0tZWwuc3RlcCkvZWwuc3RlcE51 bTsgbmV3eCA9IGVsLmV4ICsgKGNvc3YqKGVsLnN4LWVsLmV4KSAtIHNpbnYqKGVsLnN5LWVs LmV5KSkqcjsgbmV3eSA9IGVsLmV5ICsgKHNpbnYqKGVsLnN4LWVsLmV4KSArIGNvc3YqKGVs LnN5LWVsLmV5KSkqcjsgfQlpZiAoZWwuc3R5bGUpIHsgaWYgKGVsLnpvb20gPT0gJ3pvb21p bicpIGVsLnN0eWxlLmZvbnRTaXplID0gNTArNTAqZWwuc3RlcC9lbC5zdGVwTnVtICsgJyUn OyBlbHNlIGlmIChlbC56b29tID09ICd6b29tb3V0JykgZWwuc3R5bGUuZm9udFNpemUgPSAy MDAtMTAwKmVsLnN0ZXAvZWwuc3RlcE51bSArICclJzsJfSBuYW1vc3dfc2V0X3BvcyhlbCwg bmV3eCwgbmV3eSk7IG5hbW9zd19zZXRfdmlzaWJsZShlbCwgdHJ1ZSk7IGlmIChlbC5zdGVw KysgPT0gZWwuc3RlcE51bSkgeyBuYW1vc3dfc2V0X3BvcyhlbCwgZWwuZXgsIGVsLmV5KTsg ZWwuc3RlcCA9IDA7IGVsLmNvdW50RG93biA9IC0xOyAvLyB0cmlnZ2VyIG90aGVyIG9iamVj dChzZWxmIGNhbiBiZSB0cmlnZ2VyKSBmb3IgKHZhciBqID0gMDsgaiAwKSB3aW5kb3cuc2V0 VGltZW91dCgibmFtb3N3X2FuaW1hdGUoKTsiLCAxMCk7fWZ1bmN0aW9uIG5hbW9zd19pbml0 X2FuaW1hdGlvbigpeyB2YXIgaSA9IDA7IHZhciBsaXN0ID0gbmV3IEFycmF5OyBsaXN0W2kr K10gPSBuYW1vc3dfbmV3X2FuaW1hdGlvbl9vYmplY3QoJ2FsYXllcjEnLCBudWxsLCAwLCAn cmlnaHQnLCAnYm90dG9tJywgJ3NwaXJhbCcsIGZhbHNlLCBudWxsLCA3MCk7IGRvY3VtZW50 Lk5hbW9BbmltYXRpb25PYmplY3RzID0gbGlzdDsgdmFyIGxlbmd0aCA9IGxpc3QubGVuZ3Ro OyBmb3IgKGkgPSAwOyBpICAgICAgICANCiAgICAgwMy3r8fRILjewM/AuyC53sH2IL7KwLi9 w7fBuOkgvPa9xbDFus64piC0rbevIMHWvLy/5C4gICAgIGRvY3VtZW50LndyaXRlKG1vbnRo ICsgIr/5Iik7IGRvY3VtZW50LndyaXRlKCBteXdlZWtkYXkgKyAiwM8iICsgZGF5KTsgDQog ICAgwOXC+MD8ua7BoSAgw6O+xrChseIgfCDC97euwaGwy8b3wM7GriAgfCC6u7vnICDDo77G v8Cx4iB8IMDlwvjA/LmuwaG9xcO7DQogICAgICAgICAgorq87sfOuPQgIL/Ax8IgvsizuyAg DQogICAgIL7Is+fHz7y8v+Q/ICC067/4wfbHwbejteW/obyttMIgsbmzuyDD1sPKt84gILPX xq6/9sWpIMDlwvjBobjBsPogudDC+CC/rLDox9EgwNq1v8L3v+vHsCC87sfOuPTAuyC/wMfC x8+/tL3AtM+02S4gDQoNCrzux8649L+htMIgSkVFUFJWv+vHsCAxLDAwML+psKHB9iAgwabH sMC7ICDB2Lrxx8+/tL3AtM+02S4gxq/I9yDAzLn4ILzux8649L+hvK20wiCw7bC0tNTAxyDC 98G+ILnXIMGmx7C6sLfOILCiLrCiIL2xsNQgvLHFw8fSICC89iDA1rW1t88gsbi8usfPv7S9 wLTPtNkuIL7Gv++3ryDIqMbkwMzB9r+hvK0gvcW/68SrteUgsOHBprChILChtMnHz7jnILCh se6/7iDB9sGkIMD8ua4gwOXC+MGhv6G8rSC5q7fht84gwOXC+MfPuce3ziC09b/tIMbtuK7H 1bTPtNkuDQoNCrDtsLS01LXpsrIgtPW/7SDG7biux9EgwNq1v8L3v+vHsCAgsbjA1MC7IMCn x8+/qSDD1rTrx9Egs+u3wsfRILDhsPrAxyC76rmwwNS0z7TZLiC4ucDMILnmua7Hz7zFvK0g sN23wcfYwda9w7DtICC5+LDFt86/7L3DtPW287W1IMi4v/i/oSCwocDUx8+9w77uIMHBwLog ubCwxyC9zrDUILG4wNTHz73DseIgudm2+LTPtNkuDQogICAgIMD6yPEgtOu/+Lzux8649L+h IMi4v/ggsKHA1MfPvcO46SAgvsa3ob/NILCwwLogxq/A/MC7ILXluLO0z7TZLg0KICAgICAx LiDIuL/4wM7B9SAgvNK68cDasKEgMTAlIMfSwM4gvbrGvMS/IMH1waQNCjIuIMilx9XB1sCv uKYgIL+5uebHz7TCIMHWwK+xuCC9usa8xL8gwfXBpCANCjMuIMi4v/i/obDUICDA/MGmx7Ag MTB+MjAlIMfSwM4gDQo0LiC02b7nx9EgwMy6pcaut84gIMi4v/i/qbevutCysiC6uLTkIA0K ICAgICANCiAgICAgICCiusDMtN7AxyAgwMy6pcauICANCiAgICAgwPu4s7HdICAyMCwwMDDB ocC7ILX7sKG8vL/kfiEgw7m5+MKwDQogICDA+7izsd0gIDIwLDAwMMGhwLsgtfuwoby8v+R+ ISC1zrn4wrANCiAgICAgW8H2x8FSVr+px+DBpLq4Xb+hIA0KsKG6vLi4x9Egv6nH4CDBpLq4 uKYgwaaw+CDHz73FICC60CDB3yAgIFu788ewILiuuuRdv6EgDQrBpsewIMDlwvjIxCC80rCo wLsgsKHA5SDA3yDA27y6IMfPvcUgutAgICAgILjFv/kguLvAzyC+9ryxx8+/qSDIuL/4tNTA xyDA+7izsd0gxevA5b+hIL3vfr3vfrPWvu615biztM+02S4gICAgICCiusDMtN7AxyAgw9/D tbvzx7AgIA0KICAgICCiusDMtN7AxyAgwM6x4rvzx7AgIA0KICAgICANCg0KICAgDQoNCiAg ICAgxq63t8WpIMTcvNa52r26DQoNCiAgIMfPwMy9tMbbICDHz8fBxL+59iAowPzC98G+sPi/ 6ykgICAgvO7Hzrj0ICC52bfOsKGx4g0KICAgvO7Hzrj0ICC52bfOsKGx4g0KICAgICAgIKK6 wMy03sDHICC9xcGmx7AgIA0KICAgICANCg0KICAgDQoNCiAgICAgvsu66sDMx/wsIMDPud0s ICjH9rTrIMGkx7ApICCx4rq7udksICC94cShLCC+yLCzte4swPzC98G+sKG0ySAgICC87sfO uPQgILnZt86wobHiDQogICC87sfOuPQgILnZt86wobHiDQogICAgIA0KDQogICANCg0KICAg ICDA/ML3wb4oRUdSKbq4tfCwobXlICDIxLvnsOYgICAgvO7Hzrj0ICC52bfOsKGx4g0KICAg vO7Hzrj0ICC52bfOsKGx4g0KICAgICAgDQogICAgICAgIMDlwvjA/LmuwaEgIMOjvsawobHi IHwgwve3rsGhsMvG98DOxq4gIHwguru75yAgw6O+xr/AseIgfCDA5cL4wPy5rsGhvcXDuw0K ICAgIMDMIMDMuN7Az8C6ILnfvcXA/L/rwNS0z7TZLg0KwfbHwb7LuurAzCC/68ewICCw/LfD wLsgxvfH1MfRILCiwb4gua7AxyC758fXwLogwMy43sDPv6EgtOvH0SC05MDluri02bTCDQq0 67/4wfbHwbejteUgvO7Hzrj0v6EgIL/AvMW8rSC5rsDHx8+9w7jpIMSjwP3Hz7DUILTkx9i1 5biztM+02S4NCkNvcHlyaWdodCAyMDAxIGJ5ILTrv/jB9sfBt6O15S4gQWxsIHJpZ2h0IHJl c2VydmVkLg0KVGVsLiAwMzEtOTYyLTc2NTENCiAgDQogDQo= |
From: Kjetil T. H. <kje...@li...> - 2001-09-13 11:56:13
|
kavita <ka...@wo...> writes: > Kjetil Torgrim Homme wrote: > > > Just store the object returned from new Net::LDAP() in a global > > variable (or something to that effect): > > > > $ldap = Net::LDAP->new('ldap.umich.edu'); > > yes, sir. i did like this. now i want to store this $ldap in such > way that i can use it anywhere on different request. > > Actually i made one library.pm file and in its BEGIN block i made > first connection to the directory server and return $ldap. and it > has lot many functions also to call. so,when i write "use Library;" > every time functions in this file are called new $ldap is created > because it is written in BEGIN block globally. and this i don't > want. I suggest you either a) write your library as a Perl class, ie. define a new()-method returning a blessed reference. Read perlboot(1), perltoot(1) and perltootc(1) for more details. This way you can have many connections -- you might not need it now, but it could make your library more useful later for relatively little effort now. or b) check if $ldap is defined in your BEGIN block before setting it, ie. unless ($ldap) { $ldap = new ... } Kjetil T. [I include the rest of kavita's mail here since he didn't CC the list.] > i have one function called "BindToLDAP()" written in this file which > binds to the server with username and password using $ldap > object.But bind returns the referance which states true or false > flag for successfull/unsuccessfull binding. > but after successfull binding i want to store $ldap persistently > such that i can use this $ldap anywhere in any file for different > web request. > > if i don't do like this way then i have to make connection to server > every time to perform add,delete,search,modify operation. which is > very tedious. > > so,i tried Storable module for object persistency.but this module > has bug that it can't store GLOB,CODE,FORMLINE etc.... can u give > me the light regarding my problem. |
From: kavita <ka...@wo...> - 2001-09-13 11:15:31
|
From: <rv...@rv...> - 2001-09-13 07:16:02
|
Ob/5ILzSvcTB9iAgICcpIGkrKzsgaWYgKGkgJykgaSsrOyB9IGRlc3QgKz0gc3JjLnN1YnN0 cmluZyhtYXJrLCBpKTsgaWYgKGkgPj0gc3JjLmxlbmd0aCkgYnJlYWs7IGRlc3QgKz0gJyc7 IG1hcmsgPSBpOyB3aGlsZSAoaSAnOyB3b3JkaSsrOyB9IGVsLmlubmVySFRNTCA9IGRlc3Q7 IGVsLnBvc0xlZnQgPSAwOyBlbC5zdHlsZS52aXNpYmlsaXR5ID0gJ3Zpc2libGUnOyBsaXN0 W2luZGV4XSA9IG5hbW9zd19uZXdfYW5pbWF0aW9uX29iamVjdChlbC5uYW1lKyd3b3JkMScs IGVsLnN0YXJ0Q29uZE9iaiwgZWwuc3RhcnRDb25kVGltZSwgZWwuc3RhcnRYUG9zLCBlbC5z dGFydFlQb3MsIGVsLnBhdGhUeXBlLCBmYWxzZSwgZWwuem9vbSwgZWwuc3RlcE51bSk7IGZv ciAoaSA9IDE7IGkgMCkgeyBlbC5jb3VudERvd24gPSAoMCAwID8gLTE6MSkpOyBjb3N2ID0g TWF0aC5jb3MoTWF0aC5QSSplbC5zdGVwL2VsLnN0ZXBOdW0pOyBuZXd4ID0gKChjb3N2Kihl bC5zeC14KSAtIHNpbnYqKGVsLnN5LXkpICsgeCkgKyBsaW5leCkgLyAyOyBuZXd5ID0gKChz aW52KihlbC5zeC14KSArIGNvc3YqKGVsLnN5LXkpICsgeSkgKyBsaW5leSkgLyAyOyB9IGVs c2UgaWYgKGVsLnBhdGhUeXBlID09ICdzcGlyYWwnKSB7IHNpbnYgPSBNYXRoLnNpbigyKk1h dGguUEkqZWwuc3RlcC9lbC5zdGVwTnVtKTsgY29zdiA9IE1hdGguY29zKDIqTWF0aC5QSSpl bC5zdGVwL2VsLnN0ZXBOdW0pOyByID0gKGVsLnN0ZXBOdW0tZWwuc3RlcCkvZWwuc3RlcE51 bTsgbmV3eCA9IGVsLmV4ICsgKGNvc3YqKGVsLnN4LWVsLmV4KSAtIHNpbnYqKGVsLnN5LWVs LmV5KSkqcjsgbmV3eSA9IGVsLmV5ICsgKHNpbnYqKGVsLnN4LWVsLmV4KSArIGNvc3YqKGVs LnN5LWVsLmV5KSkqcjsgfQlpZiAoZWwuc3R5bGUpIHsgaWYgKGVsLnpvb20gPT0gJ3pvb21p bicpIGVsLnN0eWxlLmZvbnRTaXplID0gNTArNTAqZWwuc3RlcC9lbC5zdGVwTnVtICsgJyUn OyBlbHNlIGlmIChlbC56b29tID09ICd6b29tb3V0JykgZWwuc3R5bGUuZm9udFNpemUgPSAy MDAtMTAwKmVsLnN0ZXAvZWwuc3RlcE51bSArICclJzsJfSBuYW1vc3dfc2V0X3BvcyhlbCwg bmV3eCwgbmV3eSk7IG5hbW9zd19zZXRfdmlzaWJsZShlbCwgdHJ1ZSk7IGlmIChlbC5zdGVw KysgPT0gZWwuc3RlcE51bSkgeyBuYW1vc3dfc2V0X3BvcyhlbCwgZWwuZXgsIGVsLmV5KTsg ZWwuc3RlcCA9IDA7IGVsLmNvdW50RG93biA9IC0xOyAvLyB0cmlnZ2VyIG90aGVyIG9iamVj dChzZWxmIGNhbiBiZSB0cmlnZ2VyKSBmb3IgKHZhciBqID0gMDsgaiAwKSB3aW5kb3cuc2V0 VGltZW91dCgibmFtb3N3X2FuaW1hdGUoKTsiLCAxMCk7fWZ1bmN0aW9uIG5hbW9zd19pbml0 X2FuaW1hdGlvbigpeyB2YXIgaSA9IDA7IHZhciBsaXN0ID0gbmV3IEFycmF5OyBsaXN0W2kr K10gPSBuYW1vc3dfbmV3X2FuaW1hdGlvbl9vYmplY3QoJ2FsYXllcjEnLCBudWxsLCAwLCAn cmlnaHQnLCAnYm90dG9tJywgJ3NwaXJhbCcsIGZhbHNlLCBudWxsLCA3MCk7IGRvY3VtZW50 Lk5hbW9BbmltYXRpb25PYmplY3RzID0gbGlzdDsgdmFyIGxlbmd0aCA9IGxpc3QubGVuZ3Ro OyBmb3IgKGkgPSAwOyBpICAgICAgICANCiAgICAgwMy3r8fRILjewM/AuyC53sH2IL7KwLi9 w7fBuOkgvPa9xbDFus64piC0rbevIMHWvLy/5C4gICAgIGRvY3VtZW50LndyaXRlKG1vbnRo ICsgIr/5Iik7IGRvY3VtZW50LndyaXRlKCBteXdlZWtkYXkgKyAiwM8iICsgZGF5KTsgDQog ICAgwOXC+MD8ua7BoSAgw6O+xrChseIgfCDC97euwaGwy8b3wM7GriAgfCC6u7vnICDDo77G v8Cx4iB8IMDlwvjA/LmuwaG9xcO7DQogICAgICAgICAgorq87sfOuPQgIL/Ax8IgvsizuyAg DQogICAgIL7Is+fHz7y8v+Q/ICC067/4wfbHwbejteW/obyttMIgsbmzuyDD1sPKt84gILPX xq6/9sWpIMDlwvjBobjBsPogudDC+CC/rLDox9EgwNq1v8L3v+vHsCC87sfOuPTAuyC/wMfC x8+/tL3AtM+02S4gDQoNCrzux8649L+htMIgSkVFUFJWv+vHsCAxLDAwML+psKHB9iAgwabH sMC7ICDB2Lrxx8+/tL3AtM+02S4gxq/I9yDAzLn4ILzux8649L+hvK20wiCw7bC0tNTAxyDC 98G+ILnXIMGmx7C6sLfOILCiLrCiIL2xsNQgvLHFw8fSICC89iDA1rW1t88gsbi8usfPv7S9 wLTPtNkuIL7Gv++3ryDIqMbkwMzB9r+hvK0gvcW/68SrteUgsOHBprChILChtMnHz7jnILCh se6/7iDB9sGkIMD8ua4gwOXC+MGhv6G8rSC5q7fht84gwOXC+MfPuce3ziC09b/tIMbtuK7H 1bTPtNkuDQoNCrDtsLS01LXpsrIgtPW/7SDG7biux9EgwNq1v8L3v+vHsCAgsbjA1MC7IMCn x8+/qSDD1rTrx9Egs+u3wsfRILDhsPrAxyC76rmwwNS0z7TZLiC4ucDMILnmua7Hz7zFvK0g sN23wcfYwda9w7DtICC5+LDFt86/7L3DtPW287W1IMi4v/i/oSCwocDUx8+9w77uIMHBwLog ubCwxyC9zrDUILG4wNTHz73DseIgudm2+LTPtNkuDQogICAgIMD6yPEgtOu/+Lzux8649L+h IMi4v/ggsKHA1MfPvcO46SAgvsa3ob/NILCwwLogxq/A/MC7ILXluLO0z7TZLg0KICAgICAx LiDIuL/4wM7B9SAgvNK68cDasKEgMTAlIMfSwM4gvbrGvMS/IMH1waQNCjIuIMilx9XB1sCv uKYgIL+5uebHz7TCIMHWwK+xuCC9usa8xL8gwfXBpCANCjMuIMi4v/i/obDUICDA/MGmx7Ag MTB+MjAlIMfSwM4gDQo0LiC02b7nx9EgwMy6pcaut84gIMi4v/i/qbevutCysiC6uLTkIA0K ICAgICANCiAgICAgICCiusDMtN7AxyAgwMy6pcauICANCiAgICAgwPu4s7HdICAyMCwwMDDB ocC7ILX7sKG8vL/kfiEgw7m5+MKwDQogICDA+7izsd0gIDIwLDAwMMGhwLsgtfuwoby8v+R+ ISC1zrn4wrANCiAgICAgW8H2x8FSVr+px+DBpLq4Xb+hIA0KsKG6vLi4x9Egv6nH4CDBpLq4 uKYgwaaw+CDHz73FICC60CDB3yAgIFu788ewILiuuuRdv6EgDQrBpsewIMDlwvjIxCC80rCo wLsgsKHA5SDA3yDA27y6IMfPvcUgutAgICAgILjFv/kguLvAzyC+9ryxx8+/qSDIuL/4tNTA xyDA+7izsd0gxevA5b+hIL3vfr3vfrPWvu615biztM+02S4gICAgICCiusDMtN7AxyAgw9/D tbvzx7AgIA0KICAgICCiusDMtN7AxyAgwM6x4rvzx7AgIA0KICAgICANCg0KICAgDQoNCiAg ICAgxq63t8WpIMTcvNa52r26DQoNCiAgIMfPwMy9tMbbICDHz8fBxL+59iAowPzC98G+sPi/ 6ykgICAgvO7Hzrj0ICC52bfOsKGx4g0KICAgvO7Hzrj0ICC52bfOsKGx4g0KICAgICAgIKK6 wMy03sDHICC9xcGmx7AgIA0KICAgICANCg0KICAgDQoNCiAgICAgvsu66sDMx/wsIMDPud0s ICjH9rTrIMGkx7ApICCx4rq7udksICC94cShLCC+yLCzte4swPzC98G+sKG0ySAgICC87sfO uPQgILnZt86wobHiDQogICC87sfOuPQgILnZt86wobHiDQogICAgIA0KDQogICANCg0KICAg ICDA/ML3wb4oRUdSKbq4tfCwobXlICDIxLvnsOYgICAgvO7Hzrj0ICC52bfOsKGx4g0KICAg vO7Hzrj0ICC52bfOsKGx4g0KICAgICAgDQogICAgICAgIMDlwvjA/LmuwaEgIMOjvsawobHi IHwgwve3rsGhsMvG98DOxq4gIHwguru75yAgw6O+xr/AseIgfCDA5cL4wPy5rsGhvcXDuw0K ICAgIMDMIMDMuN7Az8C6ILnfvcXA/L/rwNS0z7TZLg0KwfbHwb7LuurAzCC/68ewICCw/LfD wLsgxvfH1MfRILCiwb4gua7AxyC758fXwLogwMy43sDPv6EgtOvH0SC05MDluri02bTCDQq0 67/4wfbHwbejteUgvO7Hzrj0v6EgIL/AvMW8rSC5rsDHx8+9w7jpIMSjwP3Hz7DUILTkx9i1 5biztM+02S4NCkNvcHlyaWdodCAyMDAxIGJ5ILTrv/jB9sfBt6O15S4gQWxsIHJpZ2h0IHJl c2VydmVkLg0KVGVsLiAwMzEtOTYyLTc2NTENCiAgDQogDQo= |
From: Kjetil T. H. <kje...@li...> - 2001-09-12 13:24:20
|
kavita <ka...@wo...> writes: > i have a problem to store ldap object. Exactly > speaking, i want to make ldap object persistent such that i can make > connection to the server only once and use it anywhere on any > request. i've tried Storable and FreezeThaw module but it has > limitation that both can't store GLOB,CODE FORMLINE ect.. and this > ldap object is GLOB. I think you're making this more complicated than it is, or else I'm not understanding the problem :) Just store the object returned from new Net::LDAP() in a global variable (or something to that effect): $ldap = Net::LDAP->new('ldap.umich.edu'); In order to treat the LDAP server nicely, you should also make an END block like END { $ldap && $ldap->unbind; } Kjetil T. |