perl.ldap

perl.ldap http://www.nntp.perl.org/group/perl.ldap/ ... Copyright 1998-2013 perl.org Wed, 19 Jun 2013 07:16:31 +0000 ask@perl.org Re: DN Comparison function by Brian Reichert On Thu, Jun 13, 2013 at 04:01:53PM +0100, Christophe Wolfhugel wrote: > On 13/06/13 15:45, Brian Reichert wrote: > > Why not do a string compare on the output of Net::LDAP::Util::canonical_dn()? > > I am not sure this would work as the canonical_dn would not change case for > the attribute values, so: > > SN=A??roport and SN=A??ROPORT would be different in string comparison, but > according to the schema still represent the same RDN. I admit my suggestion was naive. This post says that not all layers of RDN need be case-insensitive: http://comments.gmane.org/gmane.comp.ldap.umich/323 And goes on to explain that it's schema-dependant. I've not looked at the code for canonical_dn(), but I doubt it's aware of any schema. > -- > Christophe Wolfhugel -+- chris@wolfhugel.eu -- Brian Reichert <reichert@numachi.com> BSD admin/developer at large http://www.nntp.perl.org/group/perl.ldap/2013/06/msg3722.html Thu, 13 Jun 2013 16:41:04 +0000 Re: DN Comparison function by Quanah Gibson-Mount --On Thursday, June 13, 2013 4:01 PM +0100 Christophe Wolfhugel <chris@wolfhugel.eu> wrote: > On 13/06/13 15:45, Brian Reichert wrote: >> Why not do a string compare on the output of >> Net::LDAP::Util::canonical_dn()? > > I am not sure this would work as the canonical_dn would not change case > for the attribute values, so: > > SN=Aéroport and SN=AÉROPORT would be different in string comparison, but > according to the schema still represent the same RDN. lc()? --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 http://www.nntp.perl.org/group/perl.ldap/2013/06/msg3721.html Thu, 13 Jun 2013 15:36:14 +0000 Re: DN Comparison function by Christophe Wolfhugel On 13/06/13 15:45, Brian Reichert wrote: > Why not do a string compare on the output of Net::LDAP::Util::canonical_dn()? I am not sure this would work as the canonical_dn would not change case for the attribute values, so: SN=Aéroport and SN=AÉROPORT would be different in string comparison, but according to the schema still represent the same RDN. -- Christophe Wolfhugel -+- chris@wolfhugel.eu http://www.nntp.perl.org/group/perl.ldap/2013/06/msg3720.html Thu, 13 Jun 2013 15:02:09 +0000 Re: DN Comparison function by Brian Reichert On Thu, Jun 13, 2013 at 08:36:58AM +0100, Christophe Wolfhugel wrote: > Good day everyone. > > I was wondering if it would make sense to have a DN comparison function > part of Net::LDAP? Whilst in most cases a simple string comparison could > make it, there are always cases where this is not so easy, particularly > when comparison functions are not identical. Why not do a string compare on the output of Net::LDAP::Util::canonical_dn()? -- Brian Reichert <reichert@numachi.com> BSD admin/developer at large http://www.nntp.perl.org/group/perl.ldap/2013/06/msg3719.html Thu, 13 Jun 2013 14:57:26 +0000 DN Comparison function by Christophe Wolfhugel Good day everyone. I was wondering if it would make sense to have a DN comparison function part of Net::LDAP? Whilst in most cases a simple string comparison could make it, there are always cases where this is not so easy, particularly when comparison functions are not identical. See code below for a proposal on how to do this (this does not integrate yet "as is" in perl-ldap). One design question I would have is: should this be part of Net::LDAP::Schema as a metho or Net::LDAP::Util, with the schema as a provided parameter? I welcome any thoughts on this and anyone feel free to use the code if it helps you. -- Christophe Wolfhugel -+- chris@wolfhugel.eu ## $SCHEMA is a global to the selected schema we use. ## Compares 2 DNs for either equality or the first being ## part (or equal to) of a subtree represented by the ## second argument. Third argument if set tells a subtree ## comparison should be done. Returns true if identical or ## in the tree, 0 otherwise, undef if not enough arguments. sub compare_dn { return unless (@_ >= 2); return 1 if ($_[0] eq $_[1]); my $a = ldap_explode_dn($_[0]); my $b = ldap_explode_dn($_[1]); my $s = @_ == 3 ? $_[2] : 0; if ($s) { return 0 if ($#{$a} < $#${b}); splice(@{$a}, 0, $#{$a} - $#${b}); } elsif ($#{$a} != $#${b}) { return 0; } foreach my $rdn_a (@{$a}) { my $rdn_b = shift(@{$b}); return 0 if (join(',', sort keys %{$rdn_a}) ne join(',', sort keys %{$rdn_b})); while (my($attr, $v_a) = each %{$rdn_a}) { if (defined(my $v_b = delete($rdn_b->{$attr}))) { ## LDAPmatchingrule_for_attribute is my wrapper around matchingrule_for_attribute. my $mr = defined($SCHEMA) ? LDAPmatchingrule_for_attribute($SCHEMA, $attr, 'equality') : undef; $mr = defined($mr) && exists($cmpsubs{$mr}) ? $cmpsubs{$mr} : $cmpsubs{'*'}; return 0 unless (&{$mr}($v_a, $v_b)); } else { return 0; } } } return 1; } my %cmpsubs = ( '*' => sub { return $_[0] eq $_[1]; }, 'integerMatch' => sub { return $_[0] == $_[1]; }, 'caseIgnoreIA5Match' => sub { return lc($_[0]) eq lc($_[1]); }, 'caseIgnoreMatch' => sub { my @a = @_; utf8::decode($a[0]) if (utf8::valid($a[0]) && utf8::is_utf8($a[0]) == 0); utf8::decode($a[1]) if (utf8::valid($a[1]) && utf8::is_utf8($a[1]) == 0); return lc($a[0]) eq lc($a[1]); } ); http://www.nntp.perl.org/group/perl.ldap/2013/06/msg3718.html Thu, 13 Jun 2013 07:37:14 +0000 perl-ldap 0.56 released by Peter Marschall Hi all, another month, another lrease of perl-ldap: A few minutes ago I released perl-ldap 0.56 to CPAN. Find it at http://search.cpan.org/dist/perl-ldap/ The changes included are listed at the end of this email. For those of you directly pulling from GitHub, the repository https://github.com/perl-ldap/perl-ldap has been updated accordingly. Have fun with it Peter 0.56 -- Sat Jun 8 13:14:47 CEST 2013 Bug Fixes: * RT#85941: LDAP.pm: new method data_ready() * RT#84886: Control/Relax.pm: fix typo in documentation Enhancements: * FAQ.pod: add more directory servers * t/07filtermatch.t: skip some tests unless Text::Soundex is installed * t/74matchedvalues.t: new, tests for MatchedValues control * t/73assert.t: new, tests for Assertion control * LDIF.pm: overhaul - flexibilize mode handling, accept PerlIO layers - get rid of dependency on Symbol & SelectSaver - convert _write_... to object methods - use indirect file handles for URLs * LWP/Protocol/ldap.pm: use regex as 1st arg to split() -- Peter Marschall peter@adpm.de http://www.nntp.perl.org/group/perl.ldap/2013/06/msg3717.html Sat, 08 Jun 2013 12:00:30 +0000 Re: map problems by 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 http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3716.html Thu, 16 May 2013 21:40:29 +0000 Treat attribute names in LDIF change records in a case insensitivemanor. by Raymond S Brand http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3715.html Mon, 13 May 2013 20:34:58 +0000 Re: Reading LDIF files containing controls by Doug Wegscheid >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). Understood. I'm not trying to trivialize the job of the maintainer (I've been there!), but this is a simpler situation than the one that many maintainers have (this being all Perl!). The patch is not horribly complex. I understand your reservation about option hell, but think in terms of grey, not black and white, how terrible of a problem are we really looking at? >What if another patch came in asking for another RFC violation that would >negatively impact your patch? Which one should then prevail? Since the non-standards-enabling is enabled by option, I'm having a hard time thinking of a case where this would be an issue: the choices are "allow controls without change record" or "don't allow controls without change record"; we've already covered both. Not saying it can't happen, help me find a case here! In lieu of a concrete example (help me here!): if the other interfering violation were mutually exclusive, one (of several possible) approaches would be to give them different enablement options, and make the enablement options mutually exclusive. Yes, this is the start of a slippery slope into option hell, but again, how often has this come up?.  What would a conflicting option be? >Did you at least report the bug to IBM? >Because their non-standards compliant tool is the cause of the whole >discussion. I offered to as a part of quid quo pro. http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3714.html Sat, 11 May 2013 19:37:36 +0000 Re: Reading LDIF files containing controls by 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 http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3713.html Sat, 11 May 2013 19:15:10 +0000 Re: Reading LDIF files containing controls by 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. http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3712.html Sat, 11 May 2013 18:36:56 +0000 Re: Reading LDIF files containing controls by 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 http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3711.html Sat, 11 May 2013 18:22:01 +0000 Re: Reading LDIF files containing controls by Doug Wegscheid >I can understand your point of view, but it will not change my stance. not a problem. I'll ask you to think carefully the actual downside of incorporating the option for relaxing RFC compliance versus the value of said options to the open source community. What is the real downside? >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. >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? :) http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3710.html Sat, 11 May 2013 17:56:33 +0000 Re: Reading LDIF files containing controls by 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. http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3709.html Sat, 11 May 2013 17:33:43 +0000 Re: Reading LDIF files containing controls by 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 http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3708.html Sat, 11 May 2013 17:33:28 +0000 Re: Reading LDIF files containing controls by 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 http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3707.html Sat, 11 May 2013 17:03:00 +0000 Re: Reading LDIF files containing controls by 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. http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3706.html Sat, 11 May 2013 16:33:45 +0000 Re: Reading LDIF files containing controls by 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 http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3705.html Sat, 11 May 2013 16:05:45 +0000 Re: Reading LDIF files containing controls by Doug Wegscheid I don't doubt that, but the question is whether or not the patch is palatable... ________________________________ From: Quanah Gibson-Mount <quanah@zimbra.com> To: Doug Wegscheid <dwegscheid@sbcglobal.net>; perl-ldap@perl.org Sent: Tuesday, May 7, 2013 12:52 PM Subject: Re: Reading LDIF files containing controls --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 http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3704.html Tue, 07 May 2013 17:53:14 +0000 Re: Reading LDIF files containing controls by 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 http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3703.html Tue, 07 May 2013 16:53:17 +0000 Reading LDIF files containing controls by Doug Wegscheid 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. Can we consider including this patch (possibly modified if people see fit) in the next release? --- LDIF.pm~    2013-05-07 09:07:19.000000000 -0400 +++ LDIF.pm     2013-05-07 08:45:34.000000000 -0400 @@ -15,7 +15,7 @@      if (CHECK_UTF8);  } -our $VERSION = '0.20'; +our $VERSION = '0.21';  # allow the letters r,w,a as well as the well-known operators as modes  my %mode = qw(r < < < w > > > a >> >> >>); @@ -66,6 +66,7 @@      changetype => 'modify',      modify => 'add',      wrap => 78, +    controls_always_legal => 0,      %opt,      fh   => $fh,      file => "$file", @@ -352,7 +353,7 @@      my $attr;      my $xattr; -    if (@controls) { +    if (@controls && !$self->{controls_always_legal}) {        $self->_error("Controls only allowed with LDIF change entries", @ldif);        return;      } --- LDIF.pod~   2013-05-07 09:07:40.000000000 -0400 +++ LDIF.pod    2013-05-07 08:48:52.000000000 -0400 @@ -135,6 +135,11 @@  Example: raw =E<gt> qr/(?i:^jpegPhoto|;binary)/ +=item controls_always_legal =E<gt> 1 + +Always allow controls in LDIF input, even if the input LDIF entry is not +a change entry. +  =back  =back http://www.nntp.perl.org/group/perl.ldap/2013/05/msg3702.html Tue, 07 May 2013 14:00:25 +0000 Re: Net::LDAP Search Filter by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3701.html Fri, 26 Apr 2013 07:15:52 +0000 RE: Modify only one attribute that has multiple values of the samename by 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 > - http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3700.html Thu, 25 Apr 2013 17:37:05 +0000 Re: Modify only one attribute that has multiple values of the same name by 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 > - http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3699.html Thu, 25 Apr 2013 17:08:58 +0000 RE: Modify only one attribute that has multiple values of the samename by 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 - http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3698.html Thu, 25 Apr 2013 16:56:47 +0000 RE: Modify only one attribute that has multiple values of the samename by 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 - http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3697.html Thu, 25 Apr 2013 16:33:17 +0000 Re: Modify only one attribute that has multiple values of the same name by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3696.html Thu, 25 Apr 2013 16:08:02 +0000 Re: Modify only one attribute that has multiple values of the same name by 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 - http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3695.html Thu, 25 Apr 2013 16:04:21 +0000 Modify only one attribute that has multiple values of the same name by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3694.html Thu, 25 Apr 2013 15:58:03 +0000 RE: Net::LDAP Search Filter by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3693.html Thu, 25 Apr 2013 14:09:41 +0000 RE: Net::LDAP Search Filter by 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. http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3692.html Thu, 25 Apr 2013 14:07:38 +0000 Re: Net::LDAP Search Filter by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3691.html Thu, 25 Apr 2013 13:35:32 +0000 Re: Net::LDAP Search Filter by 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. http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3690.html Thu, 25 Apr 2013 13:31:25 +0000 Net::LDAP Search Filter by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3689.html Thu, 25 Apr 2013 13:27:13 +0000 Re: Problem with Net::LDAP by 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 > > http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3688.html Thu, 25 Apr 2013 12:03:43 +0000 Re: Problem with Net::LDAP by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3687.html Thu, 25 Apr 2013 11:37:34 +0000 Problem with Net::LDAP by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3686.html Thu, 25 Apr 2013 04:11:06 +0000 perl-ldap 0.55 released by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3685.html Tue, 23 Apr 2013 09:55:06 +0000 Re: Released perl-ldap 0.54 by 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 http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3684.html Fri, 05 Apr 2013 18:07:38 +0000 Re: Released perl-ldap 0.54 by 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. http://www.nntp.perl.org/group/perl.ldap/2013/04/msg3683.html Wed, 03 Apr 2013 17:56:48 +0000