You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(25) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Quanah Gibson-M. <qu...@zi...> - 2015-05-12 18:57:53
|
--On Friday, September 19, 2008 7:38 PM -0700 Quanah Gibson-Mount <qu...@zi...> wrote: > --On Friday, September 19, 2008 9:24 PM +0200 Dieter Kluenter > <di...@dk...> wrote: > > >> Sorry, misunderstanding. Here it is: > > I suspect this is the issue: > > Sep 19 18:38:56 freelancer slapd[28153]: send_search_entry: conn 52963 > ber write failed. > > Looking as to why it happens. Hi Dieter, This has been moved into github, as: <https://github.com/quanah/net-ldapapi/issues/2> We've been unable to reproduce with current OpenLDAP & Net::LDAPapi. If you are still able to reproduce the issue, feel free to update the ticket at that location. Thanks! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Quanah Gibson-M. <qu...@zi...> - 2015-05-12 17:27:25
|
Hi folks, I wanted to give an update on the project. The source code for the project has been moved to github: <https://github.com/quanah/net-ldapapi> In addition, we have a new primary developer, Phillip O'Donnell. He has been busy fixing bugs and adding new features, as well as helping scope out what will go into 3.0.4 and 3.1.x. It's great to have solid movement on the project once again. Welcome Phillip! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-20 01:57:53
|
--On Friday, September 19, 2008 9:24 PM +0200 Dieter Kluenter <di...@dk...> wrote: > Sorry, misunderstanding. Here it is: I suspect this is the issue: Sep 19 18:38:56 freelancer slapd[28153]: send_search_entry: conn 52963 ber write failed. Looking as to why it happens. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-18 13:33:35
|
--On Thursday, September 18, 2008 12:28 PM -0700 Quanah Gibson-Mount <qu...@zi...> wrote: > Thanks, this is perfect. I've certainly iterated through hundreds of > entries using Net::LDAPapi, so let me look over what's happening in > ldapwalk.pl, maybe it's got a bug the way it is written. Can you email me your current script? The basic ldapwalk.pl script works for me, with 200 entries. [zimbra@freelancer ~]$ /tmp/ldapwalk.pl uid=testuser* <snip> Found 200 records Also, if I dump it to a file and count the dn's: [zimbra@freelancer tmp]$ grep ^dn: /tmp/q.out | wc -l 200 And I verified all 200 dn's are unique. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-18 12:27:57
|
--On Thursday, September 18, 2008 8:36 PM +0200 Dieter Kluenter <di...@dk...> wrote: > Quanah Gibson-Mount <qu...@zi...> writes: > >> --On Thursday, September 18, 2008 10:29 AM -0700 Quanah Gibson-Mount >> <qu...@zi...> wrote: >> >>> --On Thursday, September 18, 2008 11:36 AM +0200 Dieter Kluenter >>> <di...@dk...> wrote: >>> >>>> ep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 BIND >>>> dn="cn=benchmark,o=avci,c=de" mech=SIMPLE ssf=0 Sep 17 19:29:11 rubin >>>> slapd[3052]: => bdb_entry_get: found entry: "cn=benchmark,o=avci,c=de" >>>> Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 RESULT tag=97 err=0 >>>> text= Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH >>>> base="ou=benchmark,o=avci,c=de" scope=1 deref=0 filter="(sn=test03*)" >>>> Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH attr=mail >>>> telephonenumber Sep 17 19:29:11 rubin slapd[3052]: => access_allowed: >>>> search access to "ou=benchmark,o=avci,c=de" "entry" requested >>> >>> >>> I suggest you alter your scope. >> >> Hm, although I guess that depends if your entries are all there on >> that level (which works fine for me). >> >> Can you get me the entire log of that particular connection, from bind >> to unbind? Same for doing the same search via ldapsearch using the >> same identity & filter, so I can compare the two. > > OK, here they are. although no visible difference. I have written a > small script that adopts most lines of ldapwalk but it works for me. If > you are interested let me know and I will mail it. I think the main > problem of ldapwalk is in the part beginning with 'Cycle Through > Entries', but I could not trace it down. > > ,----[ slapd.log ldapwalk.pl ] >| slapd[3012]: conn=33 fd=18 ACCEPT from IP=127.0.0.1:15713 >| (IP=0.0.0.0:389) slapd[3012]: conn=33 op=0 SRCH base="" scope=0 deref=0 >| filter="(objectClass=*)" slapd[3012]: conn=33 op=0 SRCH >| attr=supportedSASLMechanisms >| slapd[3012]: conn=33 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= >| slapd[3012]: conn=33 op=1 BIND dn="" method=163 >| slapd[3012]: conn=33 op=1 RESULT tag=97 err=14 text=SASL(0): successful >| result: slapd[3012]: conn=33 op=2 BIND dn="" method=163 >| slapd[3012]: SASL [conn=33] Error: unable to open Berkeley db >| /etc/sasldb2: No such file or directory slapd[3012]: conn=33 op=2 BIND >| authcid="benchmark" authzid="benchmark" slapd[3012]: conn=33 op=2 BIND >| dn="cn=benchmark,o=avci,c=de" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 >| slapd[3012]: conn=33 op=2 RESULT tag=97 err=0 text= >| slapd[3012]: conn=33 op=3 SRCH base="ou=benchmark,o=avci,c=de" scope=1 >| deref=0 filter="(sn=test03*)" slapd[3012]: conn=33 op=4 UNBIND >| slapd[3012]: conn=33 op=3 SEARCH RESULT tag=101 err=0 nentries=100 text= >| slapd[3012]: conn=33 fd=18 closed > `---- > > ,----[ slapd.log ldapsearch ] >| slapd[3012]: conn=35 fd=18 ACCEPT from IP=127.0.0.1:20256 >| (IP=0.0.0.0:389) slapd[3012]: conn=35 op=0 BIND dn="" method=163 >| slapd[3012]: conn=35 op=0 RESULT tag=97 err=14 text=SASL(0): successful >| result: slapd[3012]: conn=35 op=1 BIND dn="" method=163 >| slapd[3012]: SASL [conn=35] Error: unable to open Berkeley db >| /etc/sasldb2: No such file or directory slapd[3012]: conn=35 op=1 BIND >| authcid="benchmark" authzid="benchmark" slapd[3012]: conn=35 op=1 BIND >| dn="cn=benchmark,o=avci,c=de" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 >| slapd[3012]: conn=35 op=1 RESULT tag=97 err=0 text= >| slapd[3012]: conn=35 op=2 SRCH base="ou=benchmark,o=avci,c=de" scope=2 >| deref=0 filter="(sn=test03*)" slapd[3012]: conn=35 op=2 SRCH attr=* >| slapd[3012]: conn=35 op=3 UNBIND >| slapd[3012]: conn=35 op=2 SEARCH RESULT tag=101 err=0 nentries=100 text= >| slapd[3012]: conn=35 fd=18 closed > `---- Thanks, this is perfect. I've certainly iterated through hundreds of entries using Net::LDAPapi, so let me look over what's happening in ldapwalk.pl, maybe it's got a bug the way it is written. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Dieter K. <di...@dk...> - 2008-09-18 11:36:08
|
Quanah Gibson-Mount <qu...@zi...> writes: > --On Thursday, September 18, 2008 10:29 AM -0700 Quanah Gibson-Mount > <qu...@zi...> wrote: > >> --On Thursday, September 18, 2008 11:36 AM +0200 Dieter Kluenter >> <di...@dk...> wrote: >> >>> ep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 BIND >>> dn="cn=benchmark,o=avci,c=de" mech=SIMPLE ssf=0 Sep 17 19:29:11 rubin >>> slapd[3052]: => bdb_entry_get: found entry: "cn=benchmark,o=avci,c=de" >>> Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 RESULT tag=97 err=0 text= >>> Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH >>> base="ou=benchmark,o=avci,c=de" scope=1 deref=0 filter="(sn=test03*)" Sep >>> 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH attr=mail >>> telephonenumber Sep 17 19:29:11 rubin slapd[3052]: => access_allowed: >>> search access to "ou=benchmark,o=avci,c=de" "entry" requested >> >> >> I suggest you alter your scope. > > Hm, although I guess that depends if your entries are all there on > that level (which works fine for me). > > Can you get me the entire log of that particular connection, from bind > to unbind? Same for doing the same search via ldapsearch using the > same identity & filter, so I can compare the two. OK, here they are. although no visible difference. I have written a small script that adopts most lines of ldapwalk but it works for me. If you are interested let me know and I will mail it. I think the main problem of ldapwalk is in the part beginning with 'Cycle Through Entries', but I could not trace it down. ,----[ slapd.log ldapwalk.pl ] | slapd[3012]: conn=33 fd=18 ACCEPT from IP=127.0.0.1:15713 (IP=0.0.0.0:389) | slapd[3012]: conn=33 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" | slapd[3012]: conn=33 op=0 SRCH attr=supportedSASLMechanisms | slapd[3012]: conn=33 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= | slapd[3012]: conn=33 op=1 BIND dn="" method=163 | slapd[3012]: conn=33 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: | slapd[3012]: conn=33 op=2 BIND dn="" method=163 | slapd[3012]: SASL [conn=33] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory | slapd[3012]: conn=33 op=2 BIND authcid="benchmark" authzid="benchmark" | slapd[3012]: conn=33 op=2 BIND dn="cn=benchmark,o=avci,c=de" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 | slapd[3012]: conn=33 op=2 RESULT tag=97 err=0 text= | slapd[3012]: conn=33 op=3 SRCH base="ou=benchmark,o=avci,c=de" scope=1 deref=0 filter="(sn=test03*)" | slapd[3012]: conn=33 op=4 UNBIND | slapd[3012]: conn=33 op=3 SEARCH RESULT tag=101 err=0 nentries=100 text= | slapd[3012]: conn=33 fd=18 closed `---- ,----[ slapd.log ldapsearch ] | slapd[3012]: conn=35 fd=18 ACCEPT from IP=127.0.0.1:20256 (IP=0.0.0.0:389) | slapd[3012]: conn=35 op=0 BIND dn="" method=163 | slapd[3012]: conn=35 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: | slapd[3012]: conn=35 op=1 BIND dn="" method=163 | slapd[3012]: SASL [conn=35] Error: unable to open Berkeley db /etc/sasldb2: No such file or directory | slapd[3012]: conn=35 op=1 BIND authcid="benchmark" authzid="benchmark" | slapd[3012]: conn=35 op=1 BIND dn="cn=benchmark,o=avci,c=de" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 | slapd[3012]: conn=35 op=1 RESULT tag=97 err=0 text= | slapd[3012]: conn=35 op=2 SRCH base="ou=benchmark,o=avci,c=de" scope=2 deref=0 filter="(sn=test03*)" | slapd[3012]: conn=35 op=2 SRCH attr=* | slapd[3012]: conn=35 op=3 UNBIND | slapd[3012]: conn=35 op=2 SEARCH RESULT tag=101 err=0 nentries=100 text= | slapd[3012]: conn=35 fd=18 closed `---- -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-18 10:45:56
|
--On Thursday, September 18, 2008 10:29 AM -0700 Quanah Gibson-Mount <qu...@zi...> wrote: > --On Thursday, September 18, 2008 11:36 AM +0200 Dieter Kluenter > <di...@dk...> wrote: > >> ep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 BIND >> dn="cn=benchmark,o=avci,c=de" mech=SIMPLE ssf=0 Sep 17 19:29:11 rubin >> slapd[3052]: => bdb_entry_get: found entry: "cn=benchmark,o=avci,c=de" >> Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 RESULT tag=97 err=0 text= >> Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH >> base="ou=benchmark,o=avci,c=de" scope=1 deref=0 filter="(sn=test03*)" Sep >> 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH attr=mail >> telephonenumber Sep 17 19:29:11 rubin slapd[3052]: => access_allowed: >> search access to "ou=benchmark,o=avci,c=de" "entry" requested > > > I suggest you alter your scope. Hm, although I guess that depends if your entries are all there on that level (which works fine for me). Can you get me the entire log of that particular connection, from bind to unbind? Same for doing the same search via ldapsearch using the same identity & filter, so I can compare the two. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-18 10:29:30
|
--On Thursday, September 18, 2008 11:36 AM +0200 Dieter Kluenter <di...@dk...> wrote: > ep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 BIND > dn="cn=benchmark,o=avci,c=de" mech=SIMPLE ssf=0 Sep 17 19:29:11 rubin > slapd[3052]: => bdb_entry_get: found entry: "cn=benchmark,o=avci,c=de" > Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 RESULT tag=97 err=0 text= > Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH > base="ou=benchmark,o=avci,c=de" scope=1 deref=0 filter="(sn=test03*)" Sep > 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH attr=mail telephonenumber > Sep 17 19:29:11 rubin slapd[3052]: => access_allowed: search access to > "ou=benchmark,o=avci,c=de" "entry" requested I suggest you alter your scope. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Dieter K. <di...@dk...> - 2008-09-18 09:37:03
|
Quanah Gibson-Mount <qu...@zi...> writes: > --On Wednesday, September 17, 2008 9:53 PM +0200 Dieter Kluenter > <di...@dk...> wrote: [...] >> >> The filter is defined in ldapwalk.pl >> >> my $filter = $ARGV[0]; >> my @attrs = (); > > Again, > > What does the LDAP SERVER log as the filter it received. I'm not > asking what the script does on its side of things. If the LDAP SERVER > is not receiving the correct filter from the script because of shell > quoting issues, your lack of results makes sense. > > As I noted in my previous email a while ago, the LDAP SERVER in my > case logs: > > > Sep 17 10:18:59 freelancer slapd[28153]: conn=11826 op=2 SRCH > base="ou=people,dc=freelancer,dc=lab,dc=zimbra,dc=com" scope=2 deref=0 > filter="(uid=testus*)" OK, now I got you. I had to dig a few thausend lines but here it is: ep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 BIND dn="cn=benchmark,o=avci,c=de" mech=SIMPLE ssf=0 Sep 17 19:29:11 rubin slapd[3052]: => bdb_entry_get: found entry: "cn=benchmark,o=avci,c=de" Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=0 RESULT tag=97 err=0 text= Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH base="ou=benchmark,o=avci,c=de" scope=1 deref=0 filter="(sn=test03*)" Sep 17 19:29:11 rubin slapd[3052]: conn=19 op=1 SRCH attr=mail telephonenumber Sep 17 19:29:11 rubin slapd[3052]: => access_allowed: search access to "ou=benchmark,o=avci,c=de" "entry" requested Don't get confused by different search bases, as I do tests on different hosts, but it is the same ldapwalk.pl and the result is allways the same. By the way, I am not testing on the command line but with XEmacs and cperl mode. -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-17 20:00:54
|
--On Wednesday, September 17, 2008 12:59 PM -0700 Quanah Gibson-Mount <qu...@zi...> wrote: > which means it > (a) got a base of "ou=people,dc=freelancer,dc=lab,dc=zimbra,dc=com" --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-17 19:59:22
|
--On Wednesday, September 17, 2008 9:53 PM +0200 Dieter Kluenter <di...@dk...> wrote: > Quanah Gibson-Mount <qu...@zi...> writes: > >> --On Wednesday, September 17, 2008 9:09 PM +0200 Dieter Kluenter >> <di...@dk...> wrote: >> >>> OK, this snipped shows just the last attribute 'mobile', access has >>> been granted to all other attributs as well. >> >> My question is not what can it see or not see. My question is, what >> is it looking for? What is the filter slapd thinks was requested? >> You're example execution: > > The filter is defined in ldapwalk.pl > > my $filter = $ARGV[0]; > my @attrs = (); Again, What does the LDAP SERVER log as the filter it received. I'm not asking what the script does on its side of things. If the LDAP SERVER is not receiving the correct filter from the script because of shell quoting issues, your lack of results makes sense. As I noted in my previous email a while ago, the LDAP SERVER in my case logs: Sep 17 10:18:59 freelancer slapd[28153]: conn=11826 op=2 SRCH base="ou=people,dc=freelancer,dc=lab,dc=zimbra,dc=com" scope=2 deref=0 filter="(uid=testus*)" which means it (a) got a base of Sep 17 10:18:59 freelancer slapd[28153]: conn=11826 op=2 SRCH base="ou=people,dc=freelancer,dc=lab,dc=zimbra,dc=com" scope=2 deref=0 filter="(uid=testus*)" (b) a scope of subtree (c) and a FILTER of "(uid=testus*)" --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Dieter K. <di...@dk...> - 2008-09-17 19:53:58
|
Quanah Gibson-Mount <qu...@zi...> writes: > --On Wednesday, September 17, 2008 9:09 PM +0200 Dieter Kluenter > <di...@dk...> wrote: > >> OK, this snipped shows just the last attribute 'mobile', access has >> been granted to all other attributs as well. > > My question is not what can it see or not see. My question is, what > is it looking for? What is the filter slapd thinks was requested? > You're example execution: The filter is defined in ldapwalk.pl my $filter = $ARGV[0]; my @attrs = (); -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-17 19:12:51
|
--On Wednesday, September 17, 2008 9:09 PM +0200 Dieter Kluenter <di...@dk...> wrote: > OK, this snipped shows just the last attribute 'mobile', access has > been granted to all other attributs as well. My question is not what can it see or not see. My question is, what is it looking for? What is the filter slapd thinks was requested? You're example execution: /usr/bin/perl -w "/home/dieter/Projekte/perlscripts/ldapwalk.pl" sn=test003* I don't see any reference to "sn=test003*" in your log snippet. And, as I noted in my previous email, the problem well may be that you are not quoting your query, like: /usr/bin/perl -w "/home/dieter/Projekte/perlscripts/ldapwalk.pl" "sn=test003*" depending on your shell. As I noted, a similar query works just fine for me. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Dieter K. <di...@dk...> - 2008-09-17 19:09:23
|
Quanah Gibson-Mount <qu...@zi...> writes: > --On Wednesday, September 17, 2008 8:00 PM +0200 Dieter Kluenter > <di...@dk...> wrote: > >> Quanah Gibson-Mount <qu...@zi...> writes: >> >>> --On Wednesday, September 17, 2008 11:08 AM +0200 Dieter Kluenter >>> <di...@dk...> wrote: >>> [...] >> ,----[ slapd.log ] >>| slapd[3052]: => acl_mask: to value by "cn=dieter >>| kluenter,ou=partner,o=avci,c=de", (=0) slapd[3052]: <= check a_dn_pat: * >>| slapd[3052]: <= acl_mask: [2] applying read(=rscxd) (stop) >>| slapd[3052]: <= acl_mask: [2] mask: read(=rscxd) >>| slapd[3052]: => slap_access_allowed: read access granted by read(=rscxd) >>| slapd[3052]: => access_allowed: read access granted by read(=rscxd) >>| slapd[3052]: conn=22 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= >>| slapd[3052]: conn=22 op=4 UNBIND >>| slapd[3052]: conn=22 fd=18 closed > > This log snippet fails to include the filter that was used, which is > what I need to see. > > For example, mine shows: > > Sep 17 10:18:59 freelancer slapd[28153]: conn=11826 op=2 SRCH > base="ou=people,dc=freelancer,dc=lab,dc=zimbra,dc=com" scope=2 deref=0 > filter="(uid=testus*)" > > at stats level logging. Perhaps this is a shell issue, since you're > running this from the command line, and haven't quoted the query? OK, this snipped shows just the last attribute 'mobile', access has been granted to all other attributs as well. ,----[ slapd.log ] | [3052]: => acl_get: [4] attr mobile | [3052]: => slap_access_allowed: result not in cache (mobile) | [3052]: => acl_mask: access to entry "cn=Rosemarie Hein,ou=adressbuch,o=avci,c=de", attr "mobile" requested | [3052]: => acl_mask: to value by "cn=dieter kluenter,ou=partner,o=avci,c=de", (=0) | [3052]: <= check a_dn_pat: cn=admanager,o=avci,c=de | [3052]: <= check a_dn_pat: * | [3052]: <= acl_mask: [2] applying read(=rscxd) (stop) | [3052]: <= acl_mask: [2] mask: read(=rscxd) | [3052]: => slap_access_allowed: read access granted by read(=rscxd) | [3052]: => access_allowed: read access granted by read(=rscxd) | [3052]: conn=28 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= | [3052]: conn=28 op=4 UNBIND | [3052]: conn=28 fd=18 closed `---- -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-17 18:42:07
|
--On Wednesday, September 17, 2008 6:14 PM +0200 Dieter Kluenter <di...@dk...> wrote: > Hi, > what is the difference between ldap_sasl_bind_s and bind_s? > I modified my few lines <http://www.openldap.org/software/man.cgi?query=ldap_bind_s&apropos=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-17 18:37:31
|
--On Wednesday, September 17, 2008 5:33 PM +0200 Dieter Kluenter <di...@dk...> wrote: > ,----[ simple script perl-5.8.8 ] >| $ld = new Net::LDAPapi('localhost'); >| >| $ld->sasl_parms( >| -mech=>"DIGEST-MD5", >| -flags=>LDAP_SASL_AUTOMATIC >| ); >| >| $ld->bind_s('admanager','xxx'); >| $ld->unbind; > `---- Are you sure this is your exact script? I get no errors: [zimbra@freelancer ~]$ /tmp/ldapwalk3.pl [zimbra@freelancer ~]$ cat /tmp/ldapwalk3.pl #!/usr/bin/perl -w use strict; use Net::LDAPapi; my $ld; $ld = new Net::LDAPapi('localhost'); $ld->sasl_parms( -mech=>"DIGEST-MD5", -flags=>LDAP_SASL_AUTOMATIC ); $ld->bind_s('admanager','xxx'); $ld->unbind; --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-17 18:25:13
|
--On Wednesday, September 17, 2008 5:10 PM +0200 Dieter Kluenter <di...@dk...> wrote: > Hi, > I am testing with Net::LDAPapi, todays svn version. The following > three liner throws errors, while just stating hostname and port number > is fine. > > ,----[ simple connenction ] >| use Net::LDAPapi; >| $ld = new Net::LDAPapi( >| -url=>'ldap://localhost' >| -port=>1004); >| $ld->sasl_parms( >| -mech=> "DIGEST-MD5", >| -flag=>LDAP_SASL_QUIET); >| $ld->bind_s('admanager','xxx',LDAP_AUTH_SASL); >| $ld->unbind; > `---- It's host & port, OR url. There's no comma separating the two parameters in your code, which would also be necessary. In any case, this works for me with no error. [zimbra@freelancer tmp]$ /tmp/ldapwalk2.pl [zimbra@freelancer tmp]$ cat /tmp/ldapwalk2.pl #!/usr/bin/perl -w use strict; use Net::LDAPapi; my $ld; $ld = new Net::LDAPapi(-url=>'ldap://freelancer.lab.zimbra.com', -port=>'389'); --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-17 18:05:11
|
--On Wednesday, September 17, 2008 8:00 PM +0200 Dieter Kluenter <di...@dk...> wrote: > Quanah Gibson-Mount <qu...@zi...> writes: > >> --On Wednesday, September 17, 2008 11:08 AM +0200 Dieter Kluenter >> <di...@dk...> wrote: >> >>> I just co svn and compiled. This solved my SASL problem, but still >>> there are the known errors including '0 entries found', although slapd >>> reports 399 entries. >>> >>> /usr/bin/perl -w "/home/dieter/Projekte/perlscripts/ldapwalk.pl" >>> sn=test003* SASL/DIGEST-MD5 authentication started >>> Found 0 records >> >> >> What does the slapd log show the incoming query as? Are you sure that >> you have the digest-md5 mapping for the identity correct? It >> certainly works for me: > > Although I have mailed slapd.log already here comes it again: > > ,----[ slapd.log ] >| slapd[3052]: => acl_mask: to value by "cn=dieter >| kluenter,ou=partner,o=avci,c=de", (=0) slapd[3052]: <= check a_dn_pat: * >| slapd[3052]: <= acl_mask: [2] applying read(=rscxd) (stop) >| slapd[3052]: <= acl_mask: [2] mask: read(=rscxd) >| slapd[3052]: => slap_access_allowed: read access granted by read(=rscxd) >| slapd[3052]: => access_allowed: read access granted by read(=rscxd) >| slapd[3052]: conn=22 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= >| slapd[3052]: conn=22 op=4 UNBIND >| slapd[3052]: conn=22 fd=18 closed This log snippet fails to include the filter that was used, which is what I need to see. For example, mine shows: Sep 17 10:18:59 freelancer slapd[28153]: conn=11826 op=2 SRCH base="ou=people,dc=freelancer,dc=lab,dc=zimbra,dc=com" scope=2 deref=0 filter="(uid=testus*)" at stats level logging. Perhaps this is a shell issue, since you're running this from the command line, and haven't quoted the query? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Dieter K. <di...@dk...> - 2008-09-17 18:00:48
|
Quanah Gibson-Mount <qu...@zi...> writes: > --On Wednesday, September 17, 2008 11:08 AM +0200 Dieter Kluenter > <di...@dk...> wrote: > >> I just co svn and compiled. This solved my SASL problem, but still >> there are the known errors including '0 entries found', although slapd >> reports 399 entries. >> >> /usr/bin/perl -w "/home/dieter/Projekte/perlscripts/ldapwalk.pl" >> sn=test003* SASL/DIGEST-MD5 authentication started >> Found 0 records > > > What does the slapd log show the incoming query as? Are you sure that > you have the digest-md5 mapping for the identity correct? It > certainly works for me: Although I have mailed slapd.log already here comes it again: ,----[ slapd.log ] | slapd[3052]: => acl_mask: to value by "cn=dieter kluenter,ou=partner,o=avci,c=de", (=0) | slapd[3052]: <= check a_dn_pat: * | slapd[3052]: <= acl_mask: [2] applying read(=rscxd) (stop) | slapd[3052]: <= acl_mask: [2] mask: read(=rscxd) | slapd[3052]: => slap_access_allowed: read access granted by read(=rscxd) | slapd[3052]: => access_allowed: read access granted by read(=rscxd) | slapd[3052]: conn=22 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= | slapd[3052]: conn=22 op=4 UNBIND | slapd[3052]: conn=22 fd=18 closed | `---- -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E |
From: Quanah Gibson-M. <qu...@zi...> - 2008-09-17 17:19:02
|
--On Wednesday, September 17, 2008 11:08 AM +0200 Dieter Kluenter <di...@dk...> wrote: > I just co svn and compiled. This solved my SASL problem, but still > there are the known errors including '0 entries found', although slapd > reports 399 entries. > > /usr/bin/perl -w "/home/dieter/Projekte/perlscripts/ldapwalk.pl" > sn=test003* SASL/DIGEST-MD5 authentication started > Found 0 records What does the slapd log show the incoming query as? Are you sure that you have the digest-md5 mapping for the identity correct? It certainly works for me: [zimbra@freelancer tmp]$ ./ldapwalk.pl uid=testus* Found 1 records dn: uid=testuser,ou=people,dc=freelancer,dc=lab,dc=zimbra,dc=com zimbraId: a4a42bb0-2381-4201-82d6-ec72b5a556bd uid: testuser cn: testuser objectClass: organizationalPerson objectClass: zimbraAccount objectClass: amavisAccount zimbraMailStatus: enabled zimbraMailDeliveryAddress: tes...@fr... zimbraMailHost: freelancer.lab.zimbra.com sn: testuser zimbraMailTransport: lmtp:freelancer.lab.zimbra.com:7025 mail: tes...@fr... --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration |
From: Dieter K. <di...@dk...> - 2008-09-17 16:14:51
|
Hi, what is the difference between ldap_sasl_bind_s and bind_s? I modified my few lines ,----[ sasl_bind with perl 5.10 ] | use Net::LDAPapi; | $ld = new Net::LDAPapi('localhost'); | $ld->sasl_parms( | -mech=> "DIGEST-MD5", | -flag=>LDAP_SASL_QUIET); | $ld->ldap_sasl_bind_s( | dn=> 'admanager', | passwd=> 'dressa'); | $ld->unbind; `---- the error is: /usr/bin/perl -w "/home/dieter/Projekte/perlscripts/ersterVersuch.pl" Usage: Net::LDAPapi::ldap_sasl_bind_s(ld, dn, passwd, serverctrls, clientctrls, servercredp) at /home/dieter/Projekte/perlscripts/ersterVersuch.pl line 12. Compilation exited abnormally with code 255 at Wed Sep 17 17:48:07 While following lines are OK ,----[ bind_s with perl 5.10 ] | use Net::LDAPapi; | | $ld = new Net::LDAPapi('localhost'); | | $ld->sasl_parms( | -mech=> "DIGEST-MD5", | -flag=>LDAP_SASL_QUIET); | | $ld->bind_s('admanager','xxxx',LDAP_AUTH_SASL); | | $ld->unbind; `---- -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E |
From: Dieter K. <di...@dk...> - 2008-09-17 15:33:00
|
Hi, "Dieter Kluenter" <di...@dk...> writes: > Hi, > I am testing with Net::LDAPapi, todays svn version. The following > three liner throws errors, while just stating hostname and port number > is fine. > > ,----[ simple connenction ] > | use Net::LDAPapi; > | $ld = new Net::LDAPapi( > | -url=>'ldap://localhost' > | -port=>1004); > | $ld->sasl_parms( > | -mech=> "DIGEST-MD5", > | -flag=>LDAP_SASL_QUIET); > | $ld->bind_s('admanager','xxx',LDAP_AUTH_SASL); > | $ld->unbind; > `---- the above reported error occurs with perl-5.10, I am also testing perl-5.8.8 and now I get following error: ,----[ simple script perl-5.8.8 ] | $ld = new Net::LDAPapi('localhost'); | | $ld->sasl_parms( | -mech=>"DIGEST-MD5", | -flags=>LDAP_SASL_AUTOMATIC | ); | | $ld->bind_s('admanager','xxx'); | $ld->unbind; `---- /usr/bin/perl -w "/home/dieter/Projekte/perlscripts/ersterVersuch.pl" "Net::LDAPapi=HASH(0x816e978)" is not exported by the Net::LDAPapi module Can't continue after import errors at /home/dieter/Projekte/perlscripts/ersterVersuch.pl line 6 BEGIN failed--compilation aborted at /home/dieter/Projekte/perlscripts/ersterVersuch.pl line 6. Compilation exited abnormally with code 255 at Wed Sep 17 17:24:39 -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 |
From: Dieter K. <di...@dk...> - 2008-09-17 15:10:58
|
Hi, I am testing with Net::LDAPapi, todays svn version. The following three liner throws errors, while just stating hostname and port number is fine. ,----[ simple connenction ] | use Net::LDAPapi; | $ld = new Net::LDAPapi( | -url=>'ldap://localhost' | -port=>1004); | $ld->sasl_parms( | -mech=> "DIGEST-MD5", | -flag=>LDAP_SASL_QUIET); | $ld->bind_s('admanager','xxx',LDAP_AUTH_SASL); | $ld->unbind; `---- The error: /usr/bin/perl -w "/home/dieter/Projekte/perlscripts/ersterVersuch.pl" Argument "port" isn't numeric in subtraction (-) at /home/dieter/Projekte/perlscripts/ersterVersuch.pl line 6. Argument "ldap://localhost" isn't numeric in subtraction (-) at /home/dieter/Projekte/perlscripts/ersterVersuch.pl line 6. Odd number of elements in hash assignment at /usr/lib/perl5/site_perl/5.10.0/x86_64-linux-thread-multi/Net/LDAPapi.pm line 1938. Can't call method "sasl_parms" without a package or object reference at /home/dieter/Projekte/perlscripts/ersterVersuch.pl line 9. -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E |
From: Dieter K. <di...@dk...> - 2008-09-17 09:08:59
|
Hi Quanah, Quanah Gibson-Mount <qu...@zi...> writes: > --On Saturday, July 07, 2007 6:21 PM +0200 Dieter Kluenter > <di...@dk...> wrote: > >> Hi Quanah, >> >> Quanah Gibson-Mount <qu...@zi...> writes: >> >>> --On Tuesday, July 03, 2007 8:35 PM +0200 Dieter Kluenter >>> <di...@dk...> wrote: >>> [...] > Also, the latest from SVN has the fix for the SASL mech problem you found. I just co svn and compiled. This solved my SASL problem, but still there are the known errors including '0 entries found', although slapd reports 399 entries. /usr/bin/perl -w "/home/dieter/Projekte/perlscripts/ldapwalk.pl" sn=test003* SASL/DIGEST-MD5 authentication started SASL username: dieter SASL SSF: 128 SASL data security layer installed. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi/Net/LDAPapi.pm line 1555. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi/Net/LDAPapi.pm line 1555. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi/Net/LDAPapi.pm line 1555. Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi/Net/LDAPapi.pm line 1555. Found 0 records Compilation finished at Wed Sep 17 11:01:23 -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 |
From: Dieter K. <di...@dk...> - 2008-09-17 08:47:17
|
Hi Quanah, Quanah Gibson-Mount <qu...@zi...> writes: > --On Saturday, July 07, 2007 6:21 PM +0200 Dieter Kluenter > <di...@dk...> wrote: > >> Hi Quanah, >> >> Quanah Gibson-Mount <qu...@zi...> writes: >> >>> --On Tuesday, July 03, 2007 8:35 PM +0200 Dieter Kluenter >>> <di...@dk...> wrote: >>> >>>> Hi, >>>> I'm playing with LDAPapi and extended ldapwalk.pl with a few lines to >>>> enable dereferencing aliases, this are my lines >>>> >>>> my $deref = "search"; >>>> $ld->set_option(LDAP_OPT_SIZELIMIT,$sizelimit); >>>> $ld->set_option(LDAP_OPT_DEREF,$deref); >>>> >>>> but this lines have no effect, as expected. To my understanding a >>>> dereferencing should take place within a search string, but there are >>>> no appropriate parameters available. How to a dereference aliases with >>>> LDAPapi? >>> >>> Hi Dieter, >>> >>> I'm on vacation atm, but I'll get to this on Monday (or may Dmitri will >>> answer). Have you tried the latest source from SVN? It's a complete >>> re-write against the LDAP v3 API and may work a bit better. >> >> No I got the latest from CPAN, but I will try SVN tonight. > > Did this work for you? This mail is 1 year old, I cannot remember :-( > > Also, the latest from SVN has the fix for the SASL mech problem you found. Are you referring to my mail of yesterday? If so, I will give it a try. -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 |