From: Natxo Asenjo On Thu, May 16, 2013 at 11:27 PM, timothy adigun <2teezperl@gmail.com>wrote:

>
> Hi Natxo,
> Please see my comment below:
>
> On Thu, May 16, 2013 at 8:57 PM, Natxo Asenjo <natxo.asenjo@gmail.com>wrote:
>
>> hi,
>>
>> in a ldap script where I get a list of values of a multivalued attribute
>> like this:
>>
>> @memberof = qw( cn=group1,cn=xxx,dc=domain,dc=tld
>> cn=group2,cn=xxx,d=domain,dc=tld etc etc) ;
>>
>
> Since you use "qw", there is no need to still separate the element of
> your array with comma.
>

yes, I was not separating it, this is a normal ldap object, they contain
commas (weird, I know, it just does not surprise me any longer). So each
element is the string between the blanks. In fact the @memberof the array
is actually never like that black on white, but I get that array from
Net::LDAP after a search operation in the ldap server.

It turns out my regex was greedy and that is why it did not work. Now it is
fixed thanks to this awesome list.

Thanks for taking the time to answer my question.

--
groet,
natxo

From: Raymond S Brand

From: Peter Marschall Hi,

On Saturday, 11. May 2013, Doug Wegscheid wrote:
> Thanks for your time. The lack of response to "purity vs real-world
> usability" is disappointing.

I am sorry you see it that way, but my reason was not only "purity" as you
call it, but long term usability & compatibility.

Your patch would have scratched your itch, but the burden to keep perl-ldap
maintainable, understandable & compatible [even for that RFC violation of your
tool] would be on the maintainer(s).

What if another patch came in asking for another RFC violation that would
negatively impact your patch? Which one should then prevail?

Did you at least report the bug to IBM?
Because their non-standards compliant tool is the cause of the whole
discussion.

Best
Peter

--
Peter Marschall
peter@adpm.de

From: Doug Wegscheid Thanks for your time. The lack of response to "purity vs real-world usability" is disappointing.
>> I'm dealing with 1G+ LDIFs, and the patch *is* cleaner for me, but

>> preprocessing will work.

>When the dump utility is capable of writing to stdout, you can use a pipe.
>This way you will not need more memory, ...

correct, will not need disk. *will* more CPU, more time.

>> If I put the bug report in, will you incorporate the patch? :)
>No. [I do not want perl-ldap to look like the easier target ;-]]

purity wins over pragmatism :)

>If they do, you can throw away the preprocessor step.

I won't have a preprocessor. I have a patched Net::LDAP::LDIF! thanks to the maintainers for making it easy to patch.


If anyone is in the same situation as I, you have my permission to use the patch in my original posting.

From: Peter Marschall On Saturday, 11. May 2013, you wrote:
> >What I can offer you as some kind of consolation is an idea about a simple
> >preprocessor that filters out the illegal "control:" lines
> >
> > perl -i -p -0040 -e 's/\n //' < RFC-VIOLATING-FILE \
> >
> > | grep -vi ^control: > RFC-CONFORMING-FILE
> >[the first command is required to unwrap the wrapped lines]
> >
> >Alternatively you may add a
> > changetype: add line
> >after each unwrapped dn: line.
>
> all very good suggestions, thanks for offering them.
>
> I'm dealing with 1G+ LDIFs, and the patch *is* cleaner for me, but
> preprocessing will work.

When the dump utility is capable of writing to stdout, you can use a pipe.
This way you will not need more memory, ...

> >Please at least report it to them as a bug in their tool (even if they
> >might not react). Maybe they are not even aware of the issue.
>
> If I put the bug report in, will you incorporate the patch? :)
No. [I do not want perl-ldap to look like the easier target ;-]]

My hope is IBM will fix their bug and adhere to well-established standards.
If they do, you can throw away the preprocessor step.

Best
PEter

--
Peter Marschall
peter@adpm.de

From: Doug Wegscheid >How about writing a script to post-process the output from the dump to

>make it compliant?

That would work. At that point, I'll have parsed the 700M file, so I'll not need Net::LDAP::LDIF.

From: Peter Marschall Hi,

On Saturday, 11. May 2013, Doug Wegscheid wrote:
> >You may doubt it, but Quanah is right: your dump utility violates the RFC.
>
> please reread my earlier message: I do NOT doubt it violates the RFC (I
> know it does!). I'm sorry if a misread of what I wrote caused everyone to
> get the idea that I wasn't listening or understood Qaunah's email, and
> possibly caused a lack of sympathy for the situation I'm in and a lack of
> willingness to listen to my position...
>
> >I do not think that adding an option to accept this type of RFC violation
> >is the way to go, as it would be a precedent for further RFC-violations
> >(even if they were hidden behind options).
> >This way lies madness (or option hell).
>
> I'm not asking the maintainer to make a change that causes Net::LDAP to
> create anything that violates an RFC (I would absolutely agree with not
> going that direction). I am asking for a small change to be made to allow
> Net::LDAP to READ something that is in common use, but violates the RFC.
> Whether or not we like it, or if it violates our sense of purity, the use
> cases for dealing with software that does not follow standards is real,
> and sadly common. The model of "being strict on output, but allowing input
> of common violations" is not unheard of in these cases, and is useful in
> the real world.
>
> There is a middle road between strict adherance to the RFCs and allowing
> anarchy, and "liberal on input, strict on output" seems to be a pretty
> reasonable middle road. It allows Net::LDIF to be useful for more real
> world problems.
>
> I am asking everyone to think about that and see if it makes sense.

I can understand your point of view, but it will not change my stance.

What I can offer you as some kind of consolation is an idea about a simple
preprocessor that filters out the illegal "control:" lines
perl -i -p -0040 -e 's/\n //' < RFC-VIOLATING-FILE \
| grep -vi ^control: > RFC-CONFORMING-FILE
[the first command is required to unwrap the wrapped lines]

Alternatively you may add a
changetype: add line
after each unwrapped dn: line.

> >Instead, please get the dump utility fixed so that it adheres to the RFC.
>
> I don't have that kind of pull with IBM.

Please at least report it to them as a bug in their tool (even if they might
not react). Maybe they are not even aware of the issue.

Best
Peter

--
Peter Marschall
peter@adpm.de

From: Rick Sanders >Instead, please get the dump utility fixed so that it adheres to the RFC.
>
>> I don't have that kind of pull with IBM.

How about writing a script to post-process the output from the dump to
make it compliant?

-Rick

From: Doug Wegscheid >You may doubt it, but Quanah is right: your dump utility violates the RFC.

please reread my earlier message: I do NOT doubt it violates the RFC (I know it does!). I'm sorry if a misread of what I wrote caused everyone to get the idea that I wasn't listening or understood Qaunah's email, and possibly caused a lack of sympathy for the situation I'm in and a lack of willingness to listen to my position...

>I do not think that adding an option to accept this type of RFC violation
>is the way to go, as it would be a precedent for further RFC-violations
>(even if they were hidden behind options).
>This way lies madness (or option hell).

I'm not asking the maintainer to make a change that causes Net::LDAP to create anything that violates an RFC (I would absolutely agree with not going that direction). I am asking for a small change to be made to allow Net::LDAP to READ something that is in common use, but violates the RFC. Whether or not we like it, or if it violates our sense of purity, the use cases for dealing with software that does not follow standards is real, and sadly common. The model of "being strict on output, but allowing input of common violations" is not unheard of in these cases, and is useful in the real world.

There is a middle road between strict adherance to the RFCs and allowing anarchy, and "liberal on input, strict on output" seems to be a pretty reasonable middle road. It allows Net::LDIF to be useful for more real world problems.

I am asking everyone to think about that and see if it makes sense.

>Instead, please get the dump utility fixed so that it adheres to the RFC.


I don't have that kind of pull with IBM.

From: Peter Marschall Hi Doug,

On Tuesday, 7. May 2013, Doug Wegscheid wrote:
> I don't doubt that, but the question is whether or not the patch is
> palatable...

You may doubt it, but Quanah is right: your dump utility violates the RFC.

in the "Formal Syntax Definition of LDIF" section, RFC 2849 explicitly states
that controls may only occur in change records.

I do not think that adding an option to accept this type of RFC violation
is the way to go, as it would be a precedent for further RFC-violations
(even if they were hidden behind options).
This way lies madness (or option hell).

Instead, please get the dump utility fixed so that it adheres to the RFC.

Best
Peter

PS: Please don't top-post

--
Peter Marschall
peter@adpm.de

From: Quanah Gibson-Mount --On Tuesday, May 07, 2013 7:00 AM -0700 Doug Wegscheid
<dwegscheid@sbcglobal.net> wrote:

>
> I have a use case for analyzing LDIF dumps of our LDAP directory. The
> dump utility puts some controls in the output file, so Net::LDAP::LDIF
> won't read them, it fails with "Controls only allowed with LDIF change
> entries".
>
> I put a patch on to allow reading of controls for non-change entries by
> specifying controls_always_legal => 1 on the Net::LDAP::LDIF->new() call.

Sounds to me like your dump utility is creating LDIF that violates
<http://tools.ietf.org/html/rfc2849>

--Quanah



--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

From: Chris Ridd
On 25 Apr 2013, at 15:03, "Zachary, Carlton - Hoboken" <czachary@wiley.com> wrote:

> Thanks David.
>
> -----Original Message-----
> From: david.suarezdelis@telefonica.es [mailto:david.suarezdelis@telefonica.es]
> Sent: Thursday, April 25, 2013 9:35 AM
> To: perl-ldap@perl.org
> Subject: Re: Net::LDAP Search Filter
>
> Hi there, Carlton,
>
> The problem is that you are asking for employee types x and y, and assuming they cannot be of more than one type, this means the search will always be false.

RFC 2798 [inetOrgPerson] defines employeeType as a multi-valued attribute, so both filter items could potentially match the same entry. The AND will require the entry to contain both values, which might also be correct.

This sounds like an issue in the LDAP server. [Rushes off to check what ours does... :-)]

Chris

From: Brian Gaber Francis,

I have read it on CPAN. I guess I missed that part.

Thanks.

Brian

-----Original Message-----
From: Francis Swasey [mailto:Frank.Swasey@uvm.edu]
Sent: Thursday, April 25, 2013 1:09 PM
To: Brian Gaber
Cc: perl-ldap@perl.org
Subject: Re: Modify only one attribute that has multiple values of the same name

Brian,

What you really want is:

$del_msg = $ldap->modify( $dn,
changes => [
# delete old value
delete => [ SFTrule => [ "$old_value" ] ],
# add new value
add => [ SFTrule => [ "$new_value" ] ]
]
);

Why do both the add and delete in a single modify? So that it is treated as an atom and if EITHER fails, NEITHER happens (which is the creed -- "at the very least, do no harm")

This is straight out of the perl-ldap documentation, have you read it?

- Frank


On Apr 25, 2013, at 12:56 PM, Brian Gaber <Brian.Gaber@ssc-spc.gc.ca> wrote:

> Or should the syntax be:
>
> $del_mesg = $ldap->modify( $dn,
> delete => {
> SFTrule => [
> "$value" # Remove only this SFTrule value
> ],
> }
> );
>
> This produces a LDAP Error Code: 16 - modify/delete: SFTrule: no such
> value
>
> -----Original Message-----
> From: Brian Gaber [mailto:Brian.Gaber@ssc-spc.gc.ca]
> Sent: Thursday, April 25, 2013 12:33 PM
> To: 'Francis Swasey'
> Cc: perl-ldap@perl.org
> Subject: RE: Modify only one attribute that has multiple values of the
> same name
>
> Would this be the correct Net::LDAP syntax to delete the particular multivalued attribute?
>
> $del_mesg = $ldap->modify( $dn,
> delete => {
> member => [
> "SFTrule=$value" # Remove only this member
> ],
> }
> );
>
> I ask because I am getting this error:
>
> LDAP Error Code: 21 - member: value #0 invalid per syntax
>
> Thanks.
>
> -----Original Message-----
> From: Francis Swasey [mailto:Frank.Swasey@uvm.edu]
> Sent: Thursday, April 25, 2013 12:04 PM
> To: Brian Gaber
> Cc: perl-ldap@perl.org
> Subject: Re: Modify only one attribute that has multiple values of the
> same name
>
> On Apr 25, 2013, at 11:57 AM, Brian Gaber <Brian.Gaber@ssc-spc.gc.ca> wrote:
>
>> I have a LDAP object that contains an attribute SFTrule that can have multiple values. How do I change just one of the SFTrule attribute values?
>
>
> In pure ldif:
>
> dn: existing dn
> changetype: modify
> delete: SFTrule
> SFTrule: old value
> -
> add: SFTrule
> SFTrule: new value
> -

From: Francis Swasey Brian,

What you really want is:

$del_msg = $ldap->modify( $dn,
changes => [
# delete old value
delete => [ SFTrule => [ "$old_value" ] ],
# add new value
add => [ SFTrule => [ "$new_value" ] ]
]
);

Why do both the add and delete in a single modify? So that it is treated as an atom and if EITHER fails, NEITHER happens (which is the creed -- "at the very least, do no harm")

This is straight out of the perl-ldap documentation, have you read it?

- Frank


On Apr 25, 2013, at 12:56 PM, Brian Gaber <Brian.Gaber@ssc-spc.gc.ca> wrote:

> Or should the syntax be:
>
> $del_mesg = $ldap->modify( $dn,
> delete => {
> SFTrule => [
> "$value" # Remove only this SFTrule value
> ],
> }
> );
>
> This produces a LDAP Error Code: 16 - modify/delete: SFTrule: no such value
>
> -----Original Message-----
> From: Brian Gaber [mailto:Brian.Gaber@ssc-spc.gc.ca]
> Sent: Thursday, April 25, 2013 12:33 PM
> To: 'Francis Swasey'
> Cc: perl-ldap@perl.org
> Subject: RE: Modify only one attribute that has multiple values of the same name
>
> Would this be the correct Net::LDAP syntax to delete the particular multivalued attribute?
>
> $del_mesg = $ldap->modify( $dn,
> delete => {
> member => [
> "SFTrule=$value" # Remove only this member
> ],
> }
> );
>
> I ask because I am getting this error:
>
> LDAP Error Code: 21 - member: value #0 invalid per syntax
>
> Thanks.
>
> -----Original Message-----
> From: Francis Swasey [mailto:Frank.Swasey@uvm.edu]
> Sent: Thursday, April 25, 2013 12:04 PM
> To: Brian Gaber
> Cc: perl-ldap@perl.org
> Subject: Re: Modify only one attribute that has multiple values of the same name
>
> On Apr 25, 2013, at 11:57 AM, Brian Gaber <Brian.Gaber@ssc-spc.gc.ca> wrote:
>
>> I have a LDAP object that contains an attribute SFTrule that can have multiple values. How do I change just one of the SFTrule attribute values?
>
>
> In pure ldif:
>
> dn: existing dn
> changetype: modify
> delete: SFTrule
> SFTrule: old value
> -
> add: SFTrule
> SFTrule: new value
> -

From: Brian Gaber Or should the syntax be:

$del_mesg = $ldap->modify( $dn,
delete => {
SFTrule => [
"$value" # Remove only this SFTrule value
],
}
);

This produces a LDAP Error Code: 16 - modify/delete: SFTrule: no such value

-----Original Message-----
From: Brian Gaber [mailto:Brian.Gaber@ssc-spc.gc.ca]
Sent: Thursday, April 25, 2013 12:33 PM
To: 'Francis Swasey'
Cc: perl-ldap@perl.org
Subject: RE: Modify only one attribute that has multiple values of the same name

Would this be the correct Net::LDAP syntax to delete the particular multivalued attribute?

$del_mesg = $ldap->modify( $dn,
delete => {
member => [
"SFTrule=$value" # Remove only this member
],
}
);

I ask because I am getting this error:

LDAP Error Code: 21 - member: value #0 invalid per syntax

Thanks.

-----Original Message-----
From: Francis Swasey [mailto:Frank.Swasey@uvm.edu]
Sent: Thursday, April 25, 2013 12:04 PM
To: Brian Gaber
Cc: perl-ldap@perl.org
Subject: Re: Modify only one attribute that has multiple values of the same name

On Apr 25, 2013, at 11:57 AM, Brian Gaber <Brian.Gaber@ssc-spc.gc.ca> wrote:

> I have a LDAP object that contains an attribute SFTrule that can have multiple values. How do I change just one of the SFTrule attribute values?


In pure ldif:

dn: existing dn
changetype: modify
delete: SFTrule
SFTrule: old value
-
add: SFTrule
SFTrule: new value
-

From: Brian Gaber Would this be the correct Net::LDAP syntax to delete the particular multivalued attribute?

$del_mesg = $ldap->modify( $dn,
delete => {
member => [
"SFTrule=$value" # Remove only this member
],
}
);

I ask because I am getting this error:

LDAP Error Code: 21 - member: value #0 invalid per syntax

Thanks.

-----Original Message-----
From: Francis Swasey [mailto:Frank.Swasey@uvm.edu]
Sent: Thursday, April 25, 2013 12:04 PM
To: Brian Gaber
Cc: perl-ldap@perl.org
Subject: Re: Modify only one attribute that has multiple values of the same name

On Apr 25, 2013, at 11:57 AM, Brian Gaber <Brian.Gaber@ssc-spc.gc.ca> wrote:

> I have a LDAP object that contains an attribute SFTrule that can have multiple values. How do I change just one of the SFTrule attribute values?


In pure ldif:

dn: existing dn
changetype: modify
delete: SFTrule
SFTrule: old value
-
add: SFTrule
SFTrule: new value
-

From: Jerome Cartagena There is no such thing as "modify" on a multivalued attribute. As
mentioned by Francis, you will have to delete the value you want to change
and add a new one in place of it. The real warning is that you never
really want to use the changetype: replace on a multi-valued attribute.
This is because you will essentially be deleting-all existing value and
replacing it with the new value you are adding. Most often than not, this
is not what you want to do.

-Jerome



On Thu, Apr 25, 2013 at 9:04 AM, Francis Swasey <Frank.Swasey@uvm.edu>wrote:

> On Apr 25, 2013, at 11:57 AM, Brian Gaber <Brian.Gaber@ssc-spc.gc.ca>
> wrote:
>
> > I have a LDAP object that contains an attribute SFTrule that can have
> multiple values. How do I change just one of the SFTrule attribute values?
>
>
> In pure ldif:
>
> dn: existing dn
> changetype: modify
> delete: SFTrule
> SFTrule: old value
> -
> add: SFTrule
> SFTrule: new value
> -




--

~Jerome

From: Francis Swasey On Apr 25, 2013, at 11:57 AM, Brian Gaber <Brian.Gaber@ssc-spc.gc.ca> wrote:

> I have a LDAP object that contains an attribute SFTrule that can have multiple values. How do I change just one of the SFTrule attribute values?


In pure ldif:

dn: existing dn
changetype: modify
delete: SFTrule
SFTrule: old value
-
add: SFTrule
SFTrule: new value
-

From: Brian Gaber I have a LDAP object that contains an attribute SFTrule that can have multiple values. How do I change just one of the SFTrule attribute values?

Thanks.

Brian Gaber

From: Zachary, Carlton - Hoboken Thanks David.

-----Original Message-----
From: david.suarezdelis@telefonica.es [mailto:david.suarezdelis@telefonica.es]
Sent: Thursday, April 25, 2013 9:35 AM
To: perl-ldap@perl.org
Subject: Re: Net::LDAP Search Filter

Hi there, Carlton,

The problem is that you are asking for employee types x and y, and assuming they cannot be of more than one type, this means the search will always be false.

I am sure you are looking for entries of any type of objetclass and employee type x OR y: (& (objectclass=*) (| (employeetype=x)
(employeetype=y) ) )

This should do the work... You can probably also omit the objectclass part if the entries are nomal entries (no gruoups, roles or anything weird) and simply ask for (| (employeetype=x) (employeetype=y)

Good luck!
dwd



De:
"Zachary, Carlton - Hoboken" <czachary@wiley.com>
Para:
"perl-ldap@perl.org" <perl-ldap@perl.org>
Fecha:
25/04/2013 15:27
Asunto:
Net::LDAP Search Filter



Hello all,

I am trying to run this search against my directory service with the following filter and it returns nothing.

(&(employeetype=x)(employeetype=y)(objectclass=*))

But if I do just:

(&(employeetype=x)(objectclass=*))

Or

(&(employeetype=y)(objectclass=*))

I get search data returned.

Could some point out what's wrong with the first filter?

Thanks

_____________________________________________________________________
Mensaje analizado y protegido por Telefonica Grandes Clientes

From: Zachary, Carlton - Hoboken Thanks Graham.

-----Original Message-----
From: Graham Barr [mailto:gbarr@pobox.com]
Sent: Thursday, April 25, 2013 9:31 AM
To: Zachary, Carlton - Hoboken
Cc: perl-ldap@perl.org
Subject: Re: Net::LDAP Search Filter


On Apr 25, 2013, at 08:26 , "Zachary, Carlton - Hoboken" <czachary@wiley.com> wrote:

> Hello all,
>
> I am trying to run this search against my directory service with the following filter and it returns nothing.
>
> (&(employeetype=x)(employeetype=y)(objectclass=*))

that is checking

(employeetype=x) and (employeetype=y) and (objectclass=*)

of course

(employeetype=x) and (employeetype=y)

is always going to return an empty list unless x=y

maybe you wanted

(&(|(employeetype=x)(employeetype=y))(objectclass=*))

to get employees of type x or type y

Graham.

From: david.suarezdelis Hi there, Carlton,

The problem is that you are asking for employee types x and y, and
assuming they cannot be of more than one type, this means the search will
always be false.

I am sure you are looking for entries of any type of objetclass and
employee type x OR y: (& (objectclass=*) (| (employeetype=x)
(employeetype=y) ) )

This should do the work... You can probably also omit the objectclass part
if the entries are nomal entries (no gruoups, roles or anything weird) and
simply ask for (| (employeetype=x) (employeetype=y)

Good luck!
dwd



De:
"Zachary, Carlton - Hoboken" <czachary@wiley.com>
Para:
"perl-ldap@perl.org" <perl-ldap@perl.org>
Fecha:
25/04/2013 15:27
Asunto:
Net::LDAP Search Filter



Hello all,

I am trying to run this search against my directory service with the
following filter and it returns nothing.

(&(employeetype=x)(employeetype=y)(objectclass=*))

But if I do just:

(&(employeetype=x)(objectclass=*))

Or

(&(employeetype=y)(objectclass=*))

I get search data returned.

Could some point out what's wrong with the first filter?

Thanks

_____________________________________________________________________
Mensaje analizado y protegido por Telefonica Grandes Clientes

From: Graham Barr
On Apr 25, 2013, at 08:26 , "Zachary, Carlton - Hoboken" <czachary@wiley.com> wrote:

> Hello all,
>
> I am trying to run this search against my directory service with the following filter and it returns nothing.
>
> (&(employeetype=x)(employeetype=y)(objectclass=*))

that is checking

(employeetype=x) and (employeetype=y) and (objectclass=*)

of course

(employeetype=x) and (employeetype=y)

is always going to return an empty list unless x=y

maybe you wanted

(&(|(employeetype=x)(employeetype=y))(objectclass=*))

to get employees of type x or type y

Graham.

From: Zachary, Carlton - Hoboken Hello all,

I am trying to run this search against my directory service with the following filter and it returns nothing.

(&(employeetype=x)(employeetype=y)(objectclass=*))

But if I do just:

(&(employeetype=x)(objectclass=*))

Or

(&(employeetype=y)(objectclass=*))

I get search data returned.

Could some point out what's wrong with the first filter?

Thanks

From: ignatescu.dragos Hi Vladimir,

I tried your solution but it didn't work; the error persists.


Dragos Ignatescu

> On 24 April 2013 10:48, <ignatescu.dragos@stsnet.ro> wrote:
>
> Hi,
>
>> I have a problem with perl-ldap-0.55.
>>
>> Code:
>> #! /usr/bin/perl
>> use Net::LDAP;
>> my $ldap_server = "172.20.1.100";
>
> Will this help?
>
> my $ldap_server = "ldap://172.20.1.100/";
>
> Cheers,
>
> VL
>
>

From: Vladimir Levijev On 24 April 2013 10:48, <ignatescu.dragos@stsnet.ro> wrote:

Hi,

> I have a problem with perl-ldap-0.55.
>
> Code:
> #! /usr/bin/perl
> use Net::LDAP;
> my $ldap_server = "172.20.1.100";

Will this help?

my $ldap_server = "ldap://172.20.1.100/";

Cheers,

VL

From: ignatescu.dragos Hi,

I have a problem with perl-ldap-0.55.

Code:
#! /usr/bin/perl
use Net::LDAP;
my $ldap_server = "172.20.1.100";
my ldap = Net::LDAP -> new($ldap_server) or die "$@";


At runnig:
>perl perl_test_ldap.pl
IO::Socket::INET6: getaddrinfo: No such host is known. at
perl_test_ldap.pl line 4, <DATA> line 747.

I use Strawberry Perl 5.16.3.1 32bit on Windos XP Professional SP3


Any suggestion is welcome!

Dragos Ignatescu

From: Peter Marschall Hi folks,

I just released perl-ldap 0.55 to CPAN: http://search.cpan.org/dist/perl-ldap/
(it may take a little until the CPAN mirrors in your region get it)

As usual the changes included are listed at the end of this email.

Of course, the GitHub repository https://github.com/perl-ldap/perl-ldap
has been updated accordingly.

Enjoy
Peter


Bug Fixes:
RT#84410: PersistentSearch.pm: use $message->pop_entry() in example
RT#84774: Constant.pm: unbreak Novell eDirectory constants

Enhancements:
Control/ManageDsaIT.pm: update documentation & simplify a bit
Control/Relax.pm: new
Constant.pm: add LDAP_CONTROL_RELAX
LDAP.pod: omit space from filter in synopsis
FAQ.pod: don't talk of "2 lines" when there's only one
Extra/eDirectory.pm: fix typo, space police

--
Peter Marschall
peter@adpm.de

From: Quanah Gibson-Mount --On Wednesday, April 03, 2013 12:56 PM -0500 Graham Barr <gbarr@pobox.com>
wrote:

> but keepalive is not inherently part of LDAP any more than it is part of
> SMTP or FTP or any other protocol.

OTOH, making long term, *persistent* connections IS a part of the LDAP
protocol, and it is NOT generally something one does with SMTP or FTP. You
are comparing apples to oranges.

I see this as no different than the OpenLDAP C API having already added
support for the extended keepalive parameters ages ago when it is possible,
or otherwise silently ignoring them. It is part of the *nature* of LDAP to
allow, and *encourage* persistent connections, many of which remain idle
for long periods of time.

> But this implementation gives the impression that it is and may surprised
> someone when it silently does not do what is expected because of the host
> they ran it on.

No, this implementation allows the use of it IF it is available. My patch
specifically documents the cases in which it is. This is why documentation
is provided to the end user.

>> I.e., it doesn't in any way make Net::LDAP platform specific,
>
> No, it adds non-ldap specific implementaiton

See above. This is something that is *very* specific to the LDAP protocol.

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

From: Graham Barr
On Apr 3, 2013, at 11:58 , Quanah Gibson-Mount <quanah@zimbra.com> wrote:

> --On Friday, March 29, 2013 7:14 PM +0100 Peter Marschall <peter@adpm.de> wrote:
>
>> Hi Quanah,
>>
>> On Friday, 29. March 2013, Quanah Gibson-Mount wrote:
>>> Do you have plans to add the linux TCP keepalive bits I noted in a future
>>> release?
>>
>> I am very much in doubt about the Linux specific TCP keepalive bits.
>> I'd rather keep perl-ldap independent of specific OS peculiarities.
>>
>> Net::LDAP exposes the socket it uses via the socket() method.
>> Can't this be used to implement the things on the application side?
>
> Hi Peter,
>
> In doubt about what exactly? If you look at the patch I wrote, it does nothing unless the related perl module is installed. Any application that used Net::LDAP (such as Amavis) can then trivially set the parameters in its setup block for Net::LDAP, and it will work without error on any system, regardless of whether or not the enhanced keepalive bits are available. In fact, that's exactly what I patched amavis to do:
>
> my $ldap = Net::LDAP->new($self->{hostname},
> localaddr => $self->{localaddr},
> port => $self->{port},
> scheme => $self->{scheme},
> version => $self->{version},
> timeout => $self->{timeout},
> keepalive => 1,
> keepalive_idle => 240,
> keepalive_interval => 30,
> keepalive_probe => 10,
> );
>
> This allows amavis to set keepalive on any platform. If the platform doesn't support the enhanced directives, Net::LDAP just ignores them. It allows for future expansion if/when other platforms add support for the enhanced keepalive directives and someone adds a perl module for it ( OSX has some but not all last I checked).

but keepalive is not inherently part of LDAP any more than it is part of SMTP or FTP or any other protocol.

But this implementation gives the impression that it is and may surprised someone when it silently does not do what is expected because of the host they ran it on.

> I.e., it doesn't in any way make Net::LDAP platform specific,

No, it adds non-ldap specific implementaiton

> but it allows enhanced functionality if it is supported on the platform in a way that application authors can trivially add it to their existing code, keeping it clearly organized in their Net::LDAP instantiation blocks.

I agree with Peter's comment that it is better, IMO, for an application that cares about this to do so by using the $ldap->socket to get the socket.

Graham.

From: Quanah Gibson-Mount --On Friday, March 29, 2013 7:14 PM +0100 Peter Marschall <peter@adpm.de>
wrote:

> Hi Quanah,
>
> On Friday, 29. March 2013, Quanah Gibson-Mount wrote:
>> Do you have plans to add the linux TCP keepalive bits I noted in a future
>> release?
>
> I am very much in doubt about the Linux specific TCP keepalive bits.
> I'd rather keep perl-ldap independent of specific OS peculiarities.
>
> Net::LDAP exposes the socket it uses via the socket() method.
> Can't this be used to implement the things on the application side?

Hi Peter,

In doubt about what exactly? If you look at the patch I wrote, it does
nothing unless the related perl module is installed. Any application that
used Net::LDAP (such as Amavis) can then trivially set the parameters in
its setup block for Net::LDAP, and it will work without error on any
system, regardless of whether or not the enhanced keepalive bits are
available. In fact, that's exactly what I patched amavis to do:

my $ldap = Net::LDAP->new($self->{hostname},
localaddr => $self->{localaddr},
port => $self->{port},
scheme => $self->{scheme},
version => $self->{version},
timeout => $self->{timeout},
keepalive => 1,
keepalive_idle => 240,
keepalive_interval => 30,
keepalive_probe => 10,
);

This allows amavis to set keepalive on any platform. If the platform
doesn't support the enhanced directives, Net::LDAP just ignores them. It
allows for future expansion if/when other platforms add support for the
enhanced keepalive directives and someone adds a perl module for it ( OSX
has some but not all last I checked).

I.e., it doesn't in any way make Net::LDAP platform specific, but it allows
enhanced functionality if it is supported on the platform in a way that
application authors can trivially add it to their existing code, keeping it
clearly organized in their Net::LDAP instantiation blocks.

--Quanah


--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

From: Peter Marschall Hi Quanah,

On Friday, 29. March 2013, Quanah Gibson-Mount wrote:
> Do you have plans to add the linux TCP keepalive bits I noted in a future
> release?

I am very much in doubt about the Linux specific TCP keepalive bits.
I'd rather keep perl-ldap independent of specific OS peculiarities.

Net::LDAP exposes the socket it uses via the socket() method.
Can't this be used to implement the things on the application side?

Best
PEter
--
Peter Marschall
peter@adpm.de

From: Quanah Gibson-Mount --On Friday, March 29, 2013 5:29 PM +0100 Peter Marschall <peter@adpm.de>
wrote:

> Hi all,
>
> perl-ldap 0.54 has been released to CPAN
> http://search.cpan.org/dist/perl-ldap/
>
> Besides the usual cleanup and bug fixes, it contains some additions
> I'd like to mention:
> * conversion routines between generalizedTime and UNIX's time
> * Net::LDAP::Extra::eDirectory: extensions for use with Novell eDirectory

Hi Peter,

Do you have plans to add the linux TCP keepalive bits I noted in a future
release?

Thanks,
Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

From: Peter Marschall Hi all,

perl-ldap 0.54 has been released to CPAN
http://search.cpan.org/dist/perl-ldap/

Besides the usual cleanup and bug fixes, it contains some additions
I'd like to mention:
* conversion routines between generalizedTime and UNIX's time
* Net::LDAP::Extra::eDirectory: extensions for use with Novell eDirectory

The detailed changes are listed at the end of this email.

Of course, the GitHub repository https://github.com/perl-ldap/perl-ldap
has been updated accordingly.

Enjoy
Peter

0.54 -- Fri Mar 29 12:07:40 CET 2013

Bug Fixes:
* RT#73202: LDIF.pm: Base64-encode values ending in spaces
* RT#83815: fix typo/bug in example for root_dse

Enhancements:
* FAQ.pod: mention Dancer::Plugin::LDAP, update example
* Extra/eDirectory.pm: new; extensions for eDirectory
* Constant.pm: add constants for Novell eDirectory
* LDIF.pm: clean up handling of mode parameter
* LDIF.pm: partially support controls when reading
* Util.pm: add time conversion functions
* Makefile.PL: update recommends, add comments on core modules
* FAQ.pod: update info on required/optional modules
* LDAP.pod,FAQ.pod: harmonize documentation of scope values

--
Peter Marschall
peter@adpm.de

From: Natxo Asenjo hi,

looking at the Authen::SASL cpan page I see questions related to this module should be on this list too.

I have asked for debuggin info to sasl:

$ perl testkerb.pl adm
state(0): The routine must be called again to complete its function;Unknown error; output token sz: 621
state(0): The routine completed successfully;Unknown error; output token sz:
state(1): layermask 7,rsz 2048,lsz 16777215,choice 4
substr outside of string at /opt/perl5/perls/perl-5.14.2/lib/site_perl/5.14.4/Authen/SASL/Perl.pm line 333, <DATA> line 635.

On the ldap server logs I see I logged in and that the query was executed, but it keeps barfing.

Net::LDAP version is 0.53, Authen::SASL is 2.16 (both the latest, I think).

--
natxo

From: Natxo Asenjo On Fri, Mar 22, 2013 at 9:06 AM, Natxo Asenjo <natxo@asenjo.nl> wrote:

please ignore this message. I resent it from my gmail address because
it was not reaching the mailing list but it did reach it as I now see.

Too impatient, I guess. The problem is already solved.

--
natxo