- openldap-bugs - openldap.org

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by ando＠sys-net.it 03 Nov '06

03 Nov '06

> This overlay provides simple support for allowedAttributes and > allowedAttributesEffective, a (somewhat broken) AD feature that is > intended to > help GUIs into determining, based on the current objectClass values of an > object, what attributes would comply with the schema (without distinction > between "allowed" and "required"), by listing them in "allowedAttributes", This could be made more useful by providing ";x-allowed" or ";x-required" options to "allowedAttributes", so that GUI developers can easily handle mandatory vs. optional fields. However, I bet this would break existing applications that make use of those attributes. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4730) Overlay that generates operational attributes to support GUI interaction
by ando＠sys-net.it 03 Nov '06

03 Nov '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2006-11-03-allowed.c Submission from: (NULL) (81.72.89.40) Submitted by: ando This overlay provides simple support for allowedAttributes and allowedAttributesEffective, a (somewhat broken) AD feature that is intended to help GUIs into determining, based on the current objectClass values of an object, what attributes would comply with the schema (without distinction between "allowed" and "required"), by listing them in "allowedAttributes", and, furthermore, by providing a hint to what of those values could be effectively added by the current connection, by listing them in "allowedAttributesEffective". This is broken since it doesn't consider the possibility of value-dependent ACLs, so it should really be considered just a hint, while the "allowedAttributes" could really be computed starting from the schema definition, which remains the recommended way to solve the problem So this overlay should really be considered only food for thought as a starting base for a tighter integration of OpenLDAP into Samba4. There's minimal support for "allowedChildClasses" and "allowedChildClassesEffective", whose definition is absolutely obscure to me, as I believe the only classes that can be added to an existing object are all the AUXILIARY ones, while considering what are effectively allowed implies getting into value-dependent ACLs. Some discussion can be found here (follow the thread) <http://www.redhat.com/archives/fedora-directory-devel/2006-November/msg0000…> while portions of the schema definition has been taken from here <http://www.redhat.com/archives/fedora-directory-devel/2006-August/msg00007.…> p.

1 0

Re: (ITS#4729) Build fails in dynlist.c
by ando＠sys-net.it 02 Nov '06

02 Nov '06

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE23 > OS: SuSE Linux 10.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.4.222) > > > dynlist.c: In function 'dynlist_initialize': > dynlist.c:1401: error: 'BackendInfo' has no member named 'bi_obsolete_names' > make[3]: *** [dynlist.lo] Error 1 > make[3]: Leaving directory > `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers/slapd/overlays' > make[2]: *** [dynamic_overlays] Error 2 > make[2]: Leaving directory > `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory > `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers' > make: *** [all-common] Error 1 > My fault: some -devel stuff slipped in re23; you should remove the lines #elif SLAPD_OVER_DYNGROUP != SLAPD_MOD_STATIC #define TAKEOVER_DYNGROUP at the top of dynlist.c. I'm about to fix re23. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by quanah＠stanford.edu 02 Nov '06

02 Nov '06

--On Thursday, November 02, 2006 11:07 PM +0000 ghenry(a)suretecsystems.com wrote: > <quote who="quanah(a)stanford.edu"> >> I'd like to see this script included as well. There were two concern >> listed in the ITS: >> >> # 1) Awaiting new version with proper copyright notice. >> # 2) Need information about incorporated patches to ensure all who have >> # IPR >> in this >> script have made appropriate license grants. >> >> I know #1 has been addressed. >> >> As for #2, I grant such a release for the work I've done on the script. >> >> Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release >> for the work you've done with this script? :) > > Do you mind if I do some clean up on it? > > Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and > assumptions been made with opening files and system commands etc. > > I'll have a patch tomorrow. > > You can take it or leave it ;-) I don't mind at all, just make sure you get the very latest version. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4729) Build fails in dynlist.c
by michael＠stroeder.com 02 Nov '06

02 Nov '06

Full_Name: Michael Ströder Version: RE23 OS: SuSE Linux 10.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.4.222) dynlist.c: In function 'dynlist_initialize': dynlist.c:1401: error: 'BackendInfo' has no member named 'bi_obsolete_names' make[3]: *** [dynlist.lo] Error 1 make[3]: Leaving directory `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers/slapd/overlays' make[2]: *** [dynamic_overlays] Error 2 make[2]: Leaving directory `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/michael/src/openldap-OPENLDAP_REL_ENG_2_3/ldap/servers' make: *** [all-common] Error 1

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by ghenry＠suretecsystems.com 02 Nov '06

02 Nov '06

<quote who="quanah(a)stanford.edu"> > I'd like to see this script included as well. There were two concern > listed in the ITS: > > #1) Awaiting new version with proper copyright notice. > #2) Need information about incorporated patches to ensure all who have IPR > in this > script have made appropriate license grants. > > I know #1 has been addressed. > > As for #2, I grant such a release for the work I've done on the script. > > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release > for the work you've done with this script? :) Do you mind if I do some clean up on it? Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and assumptions been made with opening files and system commands etc. I'll have a patch tomorrow. You can take it or leave it ;-) Gavin. http://perlmonks.org/?node_id=386673 http://www.suretecsystems.com/

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by daveh＠ci.com.au 02 Nov '06

02 Nov '06

On Thu, 2 Nov 2006, Quanah Gibson-Mount wrote: > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a > release for the work you've done with this script? :) Sure; fame at last :-) -- Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by peter.schober＠univie.ac.at 02 Nov '06

02 Nov '06

quanah et al., * Quanah Gibson-Mount <quanah(a)stanford.edu> [2006-11-02 20:42]: > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a > release for the work you've done with this script? :) go ahead. actually I though about rewriting it not just once before (it's rather spaghetti-ish, imho) but too many other things keep popping up. regards, -p.schober -- peter.schober(a)univie.ac.at - vienna university computer center Universitaetsstrasse 7, A-1010 Wien, Austria/Europe Tel. +43-1-4277-14155, Fax. +43-1-4277-9140

1 0

Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by tlyons＠ivenue.com 02 Nov '06

02 Nov '06

On Thu, Nov 02, 2006 at 11:42:32AM -0800, Quanah Gibson-Mount wrote: >I'd like to see this script included as well. There were two concern >listed in the ITS: > >#1) Awaiting new version with proper copyright notice. >#2) Need information about incorporated patches to ensure all who have IPR >in this >script have made appropriate license grants. > >I know #1 has been addressed. > >As for #2, I grant such a release for the work I've done on the script. > >Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release >for the work you've done with this script? :) I do, though I don't think my work amounts to much more than one item in a foreach loop. But I do. -- Regards... Todd when you shoot yourself in the foot, just because you are so neurally broken that the signal takes years to register in your brain, it does not mean that your foot does not have a hole in it. --Randy Bush Linux kernel 2.6.17-5mdv 3 users, load average: 0.00, 0.04, 0.13

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by quanah＠stanford.edu 02 Nov '06

02 Nov '06

I'd like to see this script included as well. There were two concern listed in the ITS: #1) Awaiting new version with proper copyright notice. #2) Need information about incorporated patches to ensure all who have IPR in this script have made appropriate license grants. I know #1 has been addressed. As for #2, I grant such a release for the work I've done on the script. Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release for the work you've done with this script? :) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4728) accesslog dont write attributes removing
by hyc＠symas.com 02 Nov '06

02 Nov '06

ando(a)sys-net.it wrote: > Sounds odd; can you provide a log at level "packets" of the request with > php? I suspect it's doing something like > > dn: uid=user,ou=people,dc=example > changetype: modify > replace: autoreply > - > This was the problem, it was ignoring Replace when no values were provided. Fixed now in HEAD and RE23. > or > > dn: uid=user,ou=people,dc=example > changetype: modify > delete: autoreply > autoreply: TRUE > - > > which, although semantically equivalent to what you tried, could be handled differently by acesslog(and that would be a bug) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4728) accesslog dont write attributes removing
by ando＠sys-net.it 02 Nov '06

02 Nov '06

surnu(a)alkohol.ee wrote: > i made some test and found that if i use ldapmodify > ldapmodify -x -W -ZZ -H 'ldap://example' -D "cn=admin,dc=example" > > dn: uid=user,ou=people,dc=example > changetype: modify > add: autoreply > autoreply: TRUE > modifying entry "uid=user,ou=people,dc=example" > > dn: uid=user,ou=people,dc=example > changetype: modify > delete: autoreply > modifying entry "uid=user,ou=people,dc=example" > > and accesslog shows everything correct > > dn: reqStart=20061102130447.000000Z,cn=log,dc=example > objectClass: auditModify > structuralObjectClass: auditModify > reqStart: 20061102130447.000000Z > reqEnd: 20061102130447.000001Z > reqType: modify > reqSession: 153 > reqAuthzID: cn=admin,dc=example > reqDN: uid=user,ou=people,dc=example > reqResult: 0 > reqMod: autoReply:+ TRUE > reqMod: entryCSN:= 20061102130447Z#000000#00#000000 > reqMod: modifiersName:= cn=admin,dc=example > reqMod: modifyTimestamp:= 20061102130447Z > entryUUID: 7658ab48-febe-102a-9f6c-19ea2369af21 > creatorsName: cn=log,dc=example > createTimestamp: 20061102130447Z > entryCSN: 20061102130447Z#000000#00#000000 > modifiersName: cn=log,dc=example > modifyTimestamp: 20061102130447Z > > dn: reqStart=20061102130558.000000Z,cn=log,dc=example > objectClass: auditModify > structuralObjectClass: auditModify > reqStart: 20061102130558.000000Z > reqEnd: 20061102130558.000001Z > reqType: modify > reqSession: 153 > reqAuthzID: cn=admin,dc=example > reqDN: uid=user,ou=people,dc=example > reqResult: 0 > reqMod: autoReply:- > reqMod: entryCSN:= 20061102130558Z#000000#00#000000 > reqMod: modifiersName:= cn=admin,dc=example > reqMod: modifyTimestamp:= 20061102130558Z > entryUUID: a041e758-febe-102a-9f6d-19ea2369af21 > creatorsName: cn=log,dc=example > createTimestamp: 20061102130558Z > entryCSN: 20061102130558Z#000000#00#000000 > modifiersName: cn=log,dc=example > modifyTimestamp: 20061102130558Z > > but if i do same thing with phpldapadmin or any other php application i > get acceslog > > dn: reqStart=20061102131503.000002Z,cn=log,dc=example > objectClass: auditModify > structuralObjectClass: auditModify > reqStart: 20061102131503.000002Z > reqEnd: 20061102131503.000003Z > reqType: modify > reqSession: 180 > reqAuthzID: uid=user,ou=people,dc=example > reqDN: uid=user,ou=people,dc=example > reqResult: 0 > reqMod: autoReply:+ TRUE > reqMod: entryCSN:= 20061102131503Z#000000#00#000000 > reqMod: modifiersName:= uid=user,ou=people,dc=example > reqMod: modifyTimestamp:= 20061102131503Z > entryUUID: e55e6432-febf-102a-9f70-19ea2369af21 > creatorsName: cn=log,dc=example > createTimestamp: 20061102131503Z > entryCSN: 20061102131503Z#000000#00#000000 > modifiersName: cn=log,dc=example > modifyTimestamp: 20061102131503Z > > dn: reqStart=20061102131511.000002Z,cn=log,dc=example > objectClass: auditModify > structuralObjectClass: auditModify > reqStart: 20061102131511.000002Z > reqEnd: 20061102131511.000003Z > reqType: modify > reqSession: 182 > reqAuthzID: uid=user,ou=people,dc=example > reqDN: uid=user,ou=people,dc=example > reqResult: 0 > reqMod: entryCSN:= 20061102131511Z#000000#00#000000 > reqMod: modifiersName:= uid=user,ou=people,dc=example > reqMod: modifyTimestamp:= 20061102131511Z > entryUUID: ea4cd596-febf-102a-9f71-19ea2369af21 > creatorsName: cn=log,dc=example > createTimestamp: 20061102131511Z > entryCSN: 20061102131511Z#000000#00#000000 > modifiersName: cn=log,dc=example > modifyTimestamp: 20061102131511Z > > and if using ldap admin (http://ldapadmin.sourceforge.net/) then > accesslog is also correct. > Sounds odd; can you provide a log at level "packets" of the request with php? I suspect it's doing something like dn: uid=user,ou=people,dc=example changetype: modify replace: autoreply - or dn: uid=user,ou=people,dc=example changetype: modify delete: autoreply autoreply: TRUE - which, although semantically equivalent to what you tried, could be handled differently by acesslog(and that would be a bug) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4728) accesslog dont write attributes removing
by surnu＠alkohol.ee 02 Nov '06

02 Nov '06

i made some test and found that if i use ldapmodify ldapmodify -x -W -ZZ -H 'ldap://example' -D "cn=admin,dc=example" dn: uid=user,ou=people,dc=example changetype: modify add: autoreply autoreply: TRUE modifying entry "uid=user,ou=people,dc=example" dn: uid=user,ou=people,dc=example changetype: modify delete: autoreply modifying entry "uid=user,ou=people,dc=example" and accesslog shows everything correct dn: reqStart=20061102130447.000000Z,cn=log,dc=example objectClass: auditModify structuralObjectClass: auditModify reqStart: 20061102130447.000000Z reqEnd: 20061102130447.000001Z reqType: modify reqSession: 153 reqAuthzID: cn=admin,dc=example reqDN: uid=user,ou=people,dc=example reqResult: 0 reqMod: autoReply:+ TRUE reqMod: entryCSN:= 20061102130447Z#000000#00#000000 reqMod: modifiersName:= cn=admin,dc=example reqMod: modifyTimestamp:= 20061102130447Z entryUUID: 7658ab48-febe-102a-9f6c-19ea2369af21 creatorsName: cn=log,dc=example createTimestamp: 20061102130447Z entryCSN: 20061102130447Z#000000#00#000000 modifiersName: cn=log,dc=example modifyTimestamp: 20061102130447Z dn: reqStart=20061102130558.000000Z,cn=log,dc=example objectClass: auditModify structuralObjectClass: auditModify reqStart: 20061102130558.000000Z reqEnd: 20061102130558.000001Z reqType: modify reqSession: 153 reqAuthzID: cn=admin,dc=example reqDN: uid=user,ou=people,dc=example reqResult: 0 reqMod: autoReply:- reqMod: entryCSN:= 20061102130558Z#000000#00#000000 reqMod: modifiersName:= cn=admin,dc=example reqMod: modifyTimestamp:= 20061102130558Z entryUUID: a041e758-febe-102a-9f6d-19ea2369af21 creatorsName: cn=log,dc=example createTimestamp: 20061102130558Z entryCSN: 20061102130558Z#000000#00#000000 modifiersName: cn=log,dc=example modifyTimestamp: 20061102130558Z but if i do same thing with phpldapadmin or any other php application i get acceslog dn: reqStart=20061102131503.000002Z,cn=log,dc=example objectClass: auditModify structuralObjectClass: auditModify reqStart: 20061102131503.000002Z reqEnd: 20061102131503.000003Z reqType: modify reqSession: 180 reqAuthzID: uid=user,ou=people,dc=example reqDN: uid=user,ou=people,dc=example reqResult: 0 reqMod: autoReply:+ TRUE reqMod: entryCSN:= 20061102131503Z#000000#00#000000 reqMod: modifiersName:= uid=user,ou=people,dc=example reqMod: modifyTimestamp:= 20061102131503Z entryUUID: e55e6432-febf-102a-9f70-19ea2369af21 creatorsName: cn=log,dc=example createTimestamp: 20061102131503Z entryCSN: 20061102131503Z#000000#00#000000 modifiersName: cn=log,dc=example modifyTimestamp: 20061102131503Z dn: reqStart=20061102131511.000002Z,cn=log,dc=example objectClass: auditModify structuralObjectClass: auditModify reqStart: 20061102131511.000002Z reqEnd: 20061102131511.000003Z reqType: modify reqSession: 182 reqAuthzID: uid=user,ou=people,dc=example reqDN: uid=user,ou=people,dc=example reqResult: 0 reqMod: entryCSN:= 20061102131511Z#000000#00#000000 reqMod: modifiersName:= uid=user,ou=people,dc=example reqMod: modifyTimestamp:= 20061102131511Z entryUUID: ea4cd596-febf-102a-9f71-19ea2369af21 creatorsName: cn=log,dc=example createTimestamp: 20061102131511Z entryCSN: 20061102131511Z#000000#00#000000 modifiersName: cn=log,dc=example modifyTimestamp: 20061102131511Z and if using ldap admin (http://ldapadmin.sourceforge.net/) then accesslog is also correct.

1 0

Re: (ITS#4728) accesslog dont write attributes removing
by surnu＠alkohol.ee 01 Nov '06

01 Nov '06

> It works fine here. Does test043 in the test suite succeed or fail for you? It succeed, i send my configuration. slapd.conf: # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/samba-tng.schema include /etc/openldap/schema/myown.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/openldap/slapd.pid # List of arguments that were passed to the server argsfile /var/run/openldap/slapd.args # Read slapd.conf(5) for possible values loglevel 256 # Allow LDAPv2 for legacy clients allow bind_v2 security update_ssf=128 # Allow nof entries with single search sizelimit -1 timelimit 30 #threads threads 256 # TLS TLSCertificateFile /etc/openldap/ssl/example.crt TLSCertificateKeyFile /etc/openldap/ssl/example.key TLSCACertificateFile /etc/openldap/ssl/ca.crt # REFERRAL referral ldap://example.org # ACL include /etc/openldap/example.acl # Database conf include /etc/openldap/slapd.bdb.log.example include /etc/openldap/slapd.bdb.example slapd.bdb.log.example: database bdb suffix "cn=example_log,dc=logs" directory /var/lib/openldap-data/example/example_log rootdn "cn=example_log,dc=logs" rootpw "secret" cachesize 5000 idlcachesize 1000 checkpoint 128 30 lastmod on overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE # Indexid include /etc/openldap/slapd.log.index slapd.bdb.example: database bdb suffix "dc=example" rootdn "cn=admin,dc=example" rootpw "secret" directory "/var/lib/openldap-data/example/" cachesize 100000 idlcachesize 100000 schemacheck on checkpoint 8 15 lastmod on include /etc/openldap/slapd.index overlay accesslog logdb cn=pop_log,dc=logs logops writes logpurge 7+00:00 1+00:00 limits dn.exact="uid=sync,ou=sync,dc=example" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 1000 modulepath /usr/lib/openldap/openldap/ moduleload back_monitor database monitor rootdn "cn=monitor"

1 0

Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu 31 Oct '06

31 Oct '06

--On Tuesday, October 31, 2006 5:50 PM +0000 quanah(a)stanford.edu wrote: > > > --On Tuesday, October 31, 2006 11:07 AM +0000 Mike Woods > <mike(a)arishi.com> wrote: > >> As promised, my log entries >> >> from my ldap log we have >> >> Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 ACCEPT from >> IP=127.0.0.1:61497 (IP=0.0.0.0:340) >> Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 BIND >> dn="uid=replicator,o=menchi" method=128 >> Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 RESULT tag=97 err=49 >> text= Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=1 UNBIND >> Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 closed >> >> And from the test modules log we have this. >> >> Oct 31 10:30:58 Menchi Glue: New >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Config >> Oct 31 10:30:58 Menchi Glue: Init >> >> This is all i get, it starts up, runs through new, all the config calls >> and then init, slapd stays up and seems perfectly well but when anything >> attempts to bind to it we get nothing at all! > > I need you to reproduce the behavior involved using the "ldapsearch" > command. I'm going to elaborate on this a little more. Your operation is performing a simple bind. The BIND operation is *only* going to get passed into the PERL backend if it controls the suffix which the binding identity is attempting to bind to. Since you haven't supplied your slapd.conf information for back-perl, this is impossible to determine. However, I will note that unless your slapd.conf has: database perl suffix "o=menchi" I do not expect to see the bind operation in the perl backend. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu 31 Oct '06

31 Oct '06

--On Tuesday, October 31, 2006 11:07 AM +0000 Mike Woods <mike(a)arishi.com> wrote: > As promised, my log entries > > from my ldap log we have > > Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 ACCEPT from > IP=127.0.0.1:61497 (IP=0.0.0.0:340) > Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 BIND > dn="uid=replicator,o=menchi" method=128 > Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=0 RESULT tag=97 err=49 text= > Oct 31 11:03:01 Menchi slapd[392]: conn=65 op=1 UNBIND > Oct 31 11:03:01 Menchi slapd[392]: conn=65 fd=7 closed > > And from the test modules log we have this. > > Oct 31 10:30:58 Menchi Glue: New > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Config > Oct 31 10:30:58 Menchi Glue: Init > > This is all i get, it starts up, runs through new, all the config calls > and then init, slapd stays up and seems perfectly well but when anything > attempts to bind to it we get nothing at all! I need you to reproduce the behavior involved using the "ldapsearch" command. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4728) accesslog dont write attributes removing
by hyc＠symas.com 31 Oct '06

31 Oct '06

surnu(a)alkohol.ee wrote: > Full_Name: Andres Kahk > Version: 2.3.28 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.80.105.102) > > > if i change attribute, everythings are fine i got: > reqMod: > autoReply:= FALSE > entryCSN:= 20061031104835Z#000000#00#000000 > modifiersName:= > modifyTimestamp:= 20061031104835Z > > but if i remove attribute from object then i got: > reqMod: > entryCSN:= 20061031104852Z#000000#00#000000 > modifiersName:= > modifyTimestamp:= 20061031104852Z > > There is no entry to remove. That means the entry is removed in write server, > but it still exists in read server > > If you got any info or patch to fix this and get syncrepl work correctly, please > send it :) It works fine here. Does test043 in the test suite succeed or fail for you? It succeeds here, and it also performs modifications that delete an attribute from an entry. You'll have to provide more information, e.g. your slapd configuration would be a good start. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4728) accesslog dont write attributes removing
by surnu＠alkohol.ee 31 Oct '06

31 Oct '06

Full_Name: Andres Kahk Version: 2.3.28 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.80.105.102) if i change attribute, everythings are fine i got: reqMod: autoReply:= FALSE entryCSN:= 20061031104835Z#000000#00#000000 modifiersName:= modifyTimestamp:= 20061031104835Z but if i remove attribute from object then i got: reqMod: entryCSN:= 20061031104852Z#000000#00#000000 modifiersName:= modifyTimestamp:= 20061031104852Z There is no entry to remove. That means the entry is removed in write server, but it still exists in read server If you got any info or patch to fix this and get syncrepl work correctly, please send it :)

1 0

Re: (ITS#4727) back-perl builds with modular back_perl broken
by quanah＠OpenLDAP.org 30 Oct '06

30 Oct '06

This can be closed, the problem was tracked down to a broken build of libltdl in Debian Sarge 64-bit. sigh. --Quanah -- Quanah Gibson-Mount QA Engineer <http://www.openldap.org>

1 0

Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu 30 Oct '06

30 Oct '06

--On Monday, October 30, 2006 11:09 AM +0000 mike(a)arishi.com wrote: > Full_Name: Mike Woods > Version: 2.3.28 > OS: FreeBSD 6.1 RELEASE 4 > URL: http://geofront.co.uk/GlueTest.pm > Submission from: (NULL) (207.138.125.56) > > > When using back-perl openldap fails to call the bind methog on > connection, i've tried this with the 2.2 branch and 2.3.28 to the same > effect. > > The failure to call bind essentialy renders back-perl useless. > > I've written and attached a basic "test" module so I can see what > openldap is doing. I am unable to reproduce this issue with 2.3.28. How are you testing this? For me: ldapsearch -LLL -x -h ldap-uat00 -b o=anyorg,c=us -D "uid=quanah,o=anyorg,c=us" -w test tribes:~> And the log clearly shows bind being called: Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 fd=8 ACCEPT from IP=171.64.19.55:41385 (IP=0.0.0.0:389) Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 op=0 BIND dn="uid=quanah,o=anyorg,c=us" method=128 Oct 30 18:38:13 ldap-uat00 Glue: Bind --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4727) back-perl builds with modular back_perl broken
by quanah＠OpenLDAP.org 30 Oct '06

30 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In working to test other bugs, I found that building slapd static allows you to use back-perl, but building slapd with modular back_perl it fails to resolve symbols. Investigation ongoing. This is with perl 5.8.8. --Quanah

1 0

(ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 30 Oct '06

30 Oct '06

Full_Name: Eric Covener Version: 2.4.3 OS: ppc linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.33.49.251) I'm using 2.4.3 and trying to set SSL client certificates on a per-connection basis. A call to ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &newctx) fails in my simple test application because ldap_pvt_tls_init hasn't had a chance to call SSLeay_add_ssl_algorithms() yet. I'm not familiar enough w/ openldap to track down how this path occurs, but it seems like the code in tls.c that handles the SSL_CTX_new() in the event of LDAP_OPT_X_TLS_NEWCTX should make sure the initializer has been run by calling ldap_pvt_tls_init() (My simple test app works when I add SSLeay_add_ssl_algorithms() before ldap_set_option). The failure without the call is TLS: could not allocate default ctx (336236705).

1 0

(ITS#4725) back-perl not calling bind method
by mike＠arishi.com 30 Oct '06

30 Oct '06

Full_Name: Mike Woods Version: 2.3.28 OS: FreeBSD 6.1 RELEASE 4 URL: http://geofront.co.uk/GlueTest.pm Submission from: (NULL) (207.138.125.56) When using back-perl openldap fails to call the bind methog on connection, i've tried this with the 2.2 branch and 2.3.28 to the same effect. The failure to call bind essentialy renders back-perl useless. I've written and attached a basic "test" module so I can see what openldap is doing.

1 0

Re: (ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by hyc＠symas.com 29 Oct '06

29 Oct '06

katuev(a)dvbank.ru wrote: > Full_Name: Konstantin Katuev > Version: 2.3.28 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.137.171.26) > > > When using unicode (russian) strings for DNs & attribute values, all sofwtare > that searches thru LDAP directory returns no results when case of letters does > not match. > If case of letters matches, everything is OK. On ASCII strings search works > fine. > Older versions (2.2.x) work good. > I've upload sample data > (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) > and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) > that can reproduce this behavior. Script will find 1 record when run against > 2.2.x server and nothing on 2.3.x. Thanks for the report. This is now fixed in CVS HEAD libraries/liblunicode/ucdata/ ucgendat.c 1.40 uctable.h 1.6 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by katuev＠dvbank.ru 29 Oct '06

29 Oct '06

Full_Name: Konstantin Katuev Version: 2.3.28 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.137.171.26) When using unicode (russian) strings for DNs & attribute values, all sofwtare that searches thru LDAP directory returns no results when case of letters does not match. If case of letters matches, everything is OK. On ASCII strings search works fine. Older versions (2.2.x) work good. I've upload sample data (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) that can reproduce this behavior. Script will find 1 record when run against 2.2.x server and nothing on 2.3.x.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs