- openldap-bugs - openldap.org

Re: (ITS#5878) Unable to add users from file generated by migrate_passd.pl
by bgmilne＠staff.telkomsa.net 06 Jan '09

06 Jan '09

On Monday 05 January 2009 12:31:23 sandeep.kumbhar(a)silverarc.biz wrote: > Full_Name: Sandeep Kumbhar > Version: openldap-2.3.27-8.el5_1.3 > OS: CentOS 5.2 > URL: > Submission from: (NULL) (59.181.122.24) > > > 1. I am using below schema for my LDAP server > > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/inetorgperson.schema > include /etc/openldap/schema/nis.schema > > 2. I created local user on the same server and did the following to > generate the > > data for step 3. > > # grep 'username' /etc/passwd > /etc/openldap/passwd.username > > Ref: > <http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLD >AP_server_for_your_network#Bonus:_Exporting_LDAP_users_home_folders_with_NFS >> In general, I note that this documentation leaves a lot to be desired. > > 3. Then I used the migration perl script for converting the local users to > LDAP users. > > # /usr/share/openldap/migration/migrate_passwd.pl > /etc/openldap/passwd.username \ > /etc/openldap/username.ldif > > 4. Now after creation of the *.ldif I used the below command to add this > database > file into the LDAP server. > You should run migrate_base.pl before you add any other data generated by migrationtools. > # ldapadd -x -D "cn=Manager,dc=intra,dc=exlinuz,dc=com" -W -f > /etc/openldap/ \ > username.ldif > > 5. After typing the ldapadd command I gave the LDAP password I got the > error below > > adding new entry "uid=sandeepk,ou=People1,dc=intra,dc=exlinuz,dc=com" > ldap_add: No such object (32) > matched DN: dc=intra,dc=exlinuz,dc=com According to the error, the deepest part of this DN that exists is dc=intra,dc=exlinuz,dc=com, so you haven't created ou=People1,dc=intra,dc=exlinuz,dc=com, which migrate_base.pl would have done for you. > 6. I have created the domain.ldif and root.ldif and added them successfully > into the > LDAP Server using the official Openldap documentation. > However I could not find anything adding Unix users and therefore I used > the > > above referenced link to generate Unix users database file for LDAP. > > Please see the ldif file output by the migration script There is no bug here. Please consult the documentation of the tools you are using (migrationtools) when your spoonfeeding doesn't work perfectly. The only problem you encountered was the 'HOWTO' you used, file bugs on it instead. It is quite evident that the author of the HOWTO has not bothered to consult the documentation for migrationtools ... see the migration-tools.txt file shipped with the software. Honestly, http://www.zarb.org/~bgmilne/make_master.sh could replace about half the HOWTO, and cover something the HOWTO doesn't (migrating groups ....). Regards, Buchan

1 0

Re: (ITS#5878) Unable to add users from file generated by migrate_passd.pl
by bgmilne＠staff.telkomsa.net 06 Jan '09

06 Jan '09

On Monday 05 January 2009 12:31:23 sandeep.kumbhar(a)silverarc.biz wrote: > Full_Name: Sandeep Kumbhar > Version: openldap-2.3.27-8.el5_1.3 > OS: CentOS 5.2 > URL: > Submission from: (NULL) (59.181.122.24) > > > 1. I am using below schema for my LDAP server > > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/inetorgperson.schema > include /etc/openldap/schema/nis.schema > > 2. I created local user on the same server and did the following to > generate the > > data for step 3. > > # grep 'username' /etc/passwd > /etc/openldap/passwd.username > > Ref: > <http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLD >AP_server_for_your_network#Bonus:_Exporting_LDAP_users_home_folders_with_NFS >> In general, I note that this documentation leaves a lot to be desired. > > 3. Then I used the migration perl script for converting the local users to > LDAP users. > > # /usr/share/openldap/migration/migrate_passwd.pl > /etc/openldap/passwd.username \ > /etc/openldap/username.ldif > > 4. Now after creation of the *.ldif I used the below command to add this > database > file into the LDAP server. > You should run migrate_base.pl before you add any other data generated by migrationtools. > # ldapadd -x -D "cn=Manager,dc=intra,dc=exlinuz,dc=com" -W -f > /etc/openldap/ \ > username.ldif > > 5. After typing the ldapadd command I gave the LDAP password I got the > error below > > adding new entry "uid=sandeepk,ou=People1,dc=intra,dc=exlinuz,dc=com" > ldap_add: No such object (32) > matched DN: dc=intra,dc=exlinuz,dc=com According to the error, the deepest part of this DN that exists is dc=intra,dc=exlinuz,dc=com, so you haven't created ou=People1,dc=intra,dc=exlinuz,dc=com, which migrate_base.pl would have done for you. > 6. I have created the domain.ldif and root.ldif and added them successfully > into the > LDAP Server using the official Openldap documentation. > However I could not find anything adding Unix users and therefore I used > the > > above referenced link to generate Unix users database file for LDAP. > > Please see the ldif file output by the migration script There is no bug here. Please consult the documentation of the tools you are using (migrationtools) when your spoonfeeding doesn't work perfectly. The only problem you encountered was the 'HOWTO' you used, file bugs on it instead. It is quite evident that the author of the HOWTO has not bothered to consult the documentation for migrationtools ... see the migration-tools.txt file shipped with the software. Honestly, http://www.zarb.org/~bgmilne/make_master.sh could replace about half the HOWTO, and cover something the HOWTO doesn't (migrating groups ....). Regards, Buchan

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 06 Jan '09

06 Jan '09

--=-SUZpECi7CptfRynVUs4v Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-12-12 at 14:23 +1100, Andrew Bartlett wrote: > On Thu, 2008-12-11 at 23:22 +0100, Pierangelo Masarati wrote: > > Andrew Bartlett wrote: > > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > > >> A tentative implementation is in HEAD, please test. You need to: > > >=20 > > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally= - > > > the Samba4 side of the implementation took far longer than I expected= ). > > >=20 > > >> - configure as --enable-deref > > >> > > >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > > >> work as global overlay yet, sorry). > > >=20 > > > This is something Samba4 will need, as many of our links are > > > cross-database. But fixing this for a single DB is a big help in any > > > case. > >=20 > > Apparently this was fixed during the overlay's shakedown, as it seems t= o=20 > > work as expected when only instantiated as global. In fact, nothing wa= s=20 > > preventing it from working this way by design, it only didn't work at=20 > > some point of its evolution. Please test. >=20 > Indeed, it works well as a global. Thanks! >=20 > My only issue remaining is the clarification over the ASN.1 encoding of > the control. While I'm still confused about the ASN.1, I've coded to match OpenLDAP's current behaviour. The deref overlay seems to be working well. Many thanks! Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-SUZpECi7CptfRynVUs4v Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJYuLrz4A8Wyi0NrsRAgALAJ0b1YEcsKRo86mc2LCZbowtSyTo1gCeM3ws slxgoMVr/MkEZcEk881oaLE= =6rsz -----END PGP SIGNATURE----- --=-SUZpECi7CptfRynVUs4v--

1 0

Re: (ITS#5874) MMR does not work in refreshOnly
by hyc＠symas.com 05 Jan '09

05 Jan '09

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > After updating tests/run.in from CVS (rev 1.59) and reconfiguring, executing > test050 with SYNCMODE=ro results in a failure. The failure is not strictly > reproducible, but it always occurred to me, either affecting one or another > delete that is not propagated to all participants to the MMR pool. I've raised > the sleep time, to make sure there's no chance replication did not occur yet. > > I wonder if refreshOnly makes any sense for a MMR pool. If it doesn't, it > should not be allowed. If it does, deletes should be replicated correctly. This sounds like a dup of #5843. Note that you cannot disallow MMR for refreshOnly, since servers must be able to refresh when starting up. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5878) Unable to add users from file generated by migrate_passd.pl
by sandeep.kumbhar＠silverarc.biz 05 Jan '09

05 Jan '09

Full_Name: Sandeep Kumbhar Version: openldap-2.3.27-8.el5_1.3 OS: CentOS 5.2 URL: Submission from: (NULL) (59.181.122.24) 1. I am using below schema for my LDAP server include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema 2. I created local user on the same server and did the following to generate the data for step 3. # grep 'username' /etc/passwd > /etc/openldap/passwd.username Ref: <http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDA…> 3. Then I used the migration perl script for converting the local users to LDAP users. # /usr/share/openldap/migration/migrate_passwd.pl /etc/openldap/passwd.username \ /etc/openldap/username.ldif 4. Now after creation of the *.ldif I used the below command to add this database file into the LDAP server. # ldapadd -x -D "cn=Manager,dc=intra,dc=exlinuz,dc=com" -W -f /etc/openldap/ \ username.ldif 5. After typing the ldapadd command I gave the LDAP password I got the error below adding new entry "uid=sandeepk,ou=People1,dc=intra,dc=exlinuz,dc=com" ldap_add: No such object (32) matched DN: dc=intra,dc=exlinuz,dc=com 6. I have created the domain.ldif and root.ldif and added them successfully into the LDAP Server using the official Openldap documentation. However I could not find anything adding Unix users and therefore I used the above referenced link to generate Unix users database file for LDAP. Please see the ldif file output by the migration script dn: uid=samk,ou=People1,dc=intra,dc=exlinuz,dc=com uid: samk cn: samk objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: {crypt}$1$eBNsXmF1$L9/bK4vbjkAOCKa5DKKAE0 shadowLastChange: 14249 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 500 gidNumber: 500 homeDirectory: /home/samk

1 0

(ITS#5877) restrict features to subset of DIT by subtree specification
by ando＠sys-net.it 30 Dec '08

30 Dec '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Many features could benefit from being restricted to a(n extended) X.501 subtree specification using a common interface (API, configuration). Examples are: - ACL - limits - custom functionalities provided by overlays p.

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by ando＠sys-net.it 30 Dec '08

30 Dec '08

rlvcosta(a)yahoo.com wrote: > --0-1358063323-1230648878=:64021 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > Pierangelo, > > I could run the valgrind but at this time I do not have the DB with the aro= > und 4 million subscribers. In this condition, with a small number of users,= > I already could see some "definitive" memory leaks and I believe they are = > associated with OpenLdap. > > Just for a history I already compiled the openldap 2.4.11 souce code withou= > t modules and TLS since many lists make reference to some possible issues i= > n RHEL with TLS. Even so I could not have a load without the possible memor= > y leak. > > So I do not believe the problems are in the RHEL libtool or glibc. > > In any case the result for the valgrind is (short number of entrances at th= > is time): You probably need to use an unstripped binary in order to find out where mallocs/frees occur. Most of the occurrences you notice are either one-time leaks. Moreover, 2.4.13 is out, and it might have fixed some. I suggest you further investigate using the latest code, using an unstripped binary. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 30 Dec '08

30 Dec '08

--0-1358063323-1230648878=:64021 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Pierangelo, I could run the valgrind but at this time I do not have the DB with the aro= und 4 million subscribers. In this condition, with a small number of users,= I already could see some "definitive" memory leaks and I believe they are = associated with OpenLdap. Just for a history I already compiled the openldap 2.4.11 souce code withou= t modules and TLS since many lists make reference to some possible issues i= n RHEL with TLS. Even so I could not have a load without the possible memor= y leak. So I do not believe the problems are in the RHEL libtool or glibc. In any case the result for the valgrind is (short number of entrances at th= is time): =3D=3D32608=3D=3D Memcheck, a memory error detector. =3D=3D32608=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D32608=3D=3D Using LibVEX rev 1575, a library for dynamic binary trans= lation. =3D=3D32608=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. =3D=3D32608=3D=3D Using valgrind-3.1.1, a dynamic binary instrumentation fr= amework. =3D=3D32608=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D32608=3D=3D For more details, rerun with: -v =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 86 f= rom 2) =3D=3D32608=3D=3D malloc/free: in use at exit: 751 bytes in 32 blocks. =3D=3D32608=3D=3D malloc/free: 29,775 allocs, 29,743 frees, 22,150,722 byte= s allocated. =3D=3D32608=3D=3D For counts of detected errors, rerun with: -v =3D=3D32608=3D=3D searching for pointers to 32 not-freed blocks. =3D=3D32608=3D=3D checked 8,191,292 bytes. =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D 16 bytes in 1 blocks are still reachable in loss record 1= of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x40056BF: calloc (vg_replace_malloc.c:279) =3D=3D32608=3D=3D=A0=A0=A0 by 0x519364: _dlerror_run (in /lib/libdl-2.3.4.s= o) =3D=3D32608=3D=3D=A0=A0=A0 by 0x518D10: dlopen@@GLIBC_2.1 (in /lib/libdl-2.= 3.4.so) =3D=3D32608=3D=3D=A0=A0=A0 by 0x52D80D: _sasl_get_plugin (in /usr/lib/libsa= sl2.so.2.0.19) =3D=3D32608=3D=3D=A0=A0=A0 by 0x52DC61: _sasl_load_plugins (in /usr/lib/lib= sasl2.so.2.0.19) =3D=3D32608=3D=3D=A0=A0=A0 by 0x52B063: sasl_server_init (in /usr/lib/libsa= sl2.so.2.0.19) =3D=3D32608=3D=3D=A0=A0=A0 by 0x80C82C0: slap_sasl_init (in /usr/libexec/sl= apd) =3D=3D32608=3D=3D=A0=A0=A0 by 0x3FFDE2: (below main) (in /lib/tls/libc-2.3.= 4.so) =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D 22 bytes in 1 blocks are still reachable in loss record 2= of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x4004405: malloc (vg_replace_malloc.c:149) =3D=3D32608=3D=3D=A0=A0=A0 by 0xB77567: (within /usr/lib/libltdl.so.3.1.0) =3D=3D32608=3D=3D=A0=A0=A0 by 0xB780C8: (within /usr/lib/libltdl.so.3.1.0) =3D=3D32608=3D=3D=A0=A0=A0 by 0xB7A79D: lt_dlsetsearchpath (in /usr/lib/lib= ltdl.so.3.1.0) =3D=3D32608=3D=3D=A0=A0=A0 by 0x8068147: (within /usr/libexec/slapd) =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D 24 bytes in 1 blocks are still reachable in loss record 3= of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x400579F: realloc (vg_replace_malloc.c:306) =3D=3D32608=3D=3D=A0=A0=A0 by 0x8151E6F: ber_bvarray_add (in /usr/libexec/s= lapd) =3D=3D32608=3D=3D=A0=A0=A0 by 0x44DD627: ??? =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D 28 bytes in 2 blocks are definitely lost in loss record 4= of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x4004405: malloc (vg_replace_malloc.c:149) =3D=3D32608=3D=3D=A0=A0=A0 by 0xB77567: (within /usr/lib/libltdl.so.3.1.0) =3D=3D32608=3D=3D=A0=A0=A0 by 0xB780C8: (within /usr/lib/libltdl.so.3.1.0) =3D=3D32608=3D=3D=A0=A0=A0 by 0xB78CDC: (within /usr/lib/libltdl.so.3.1.0) =3D=3D32608=3D=3D=A0=A0=A0 by 0xB7972B: lt_dlopen (in /usr/lib/libltdl.so.3= .1.0) =3D=3D32608=3D=3D=A0=A0=A0 by 0xB7980C: lt_dlopenext (in /usr/lib/libltdl.s= o.3.1.0) =3D=3D32608=3D=3D=A0=A0=A0 by 0x80CA1E3: module_load (in /usr/libexec/slapd= ) =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D 28 bytes in 1 blocks are still reachable in loss record 5= of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x4004405: malloc (vg_replace_malloc.c:149) =3D=3D32608=3D=3D=A0=A0=A0 by 0x3D81D7: _dl_map_object_deps (in /lib/ld-2.3= .4.so) =3D=3D32608=3D=3D=A0=A0=A0 by 0x4E7158: dl_open_worker (in /lib/tls/libc-2.= 3.4.so) =3D=3D32608=3D=3D=A0=A0=A0 by 0x3D90FD: _dl_catch_error (in /lib/ld-2.3.4.s= o) =3D=3D32608=3D=3D=A0=A0=A0 by 0x4E7CB7: _dl_open (in /lib/tls/libc-2.3.4.so= ) =3D=3D32608=3D=3D=A0=A0=A0 by 0x4E904C: do_dlopen (in /lib/tls/libc-2.3.4.s= o) =3D=3D32608=3D=3D=A0=A0=A0 by 0x3D90FD: _dl_catch_error (in /lib/ld-2.3.4.s= o) =3D=3D32608=3D=3D=A0=A0=A0 by 0x4E912D: __libc_dlopen_mode (in /lib/tls/lib= c-2.3.4.so) =3D=3D32608=3D=3D=A0=A0=A0 by 0x561087: pthread_cancel_init (in /lib/tls/li= bpthread-2.3.4.so) =3D=3D32608=3D=3D=A0=A0=A0 by 0x5611FC: _Unwind_ForcedUnwind (in /lib/tls/l= ibpthread-2.3.4.so) =3D=3D32608=3D=3D=A0=A0=A0 by 0x55F020: __pthread_unwind (in /lib/tls/libpt= hread-2.3.4.so) =3D=3D32608=3D=3D=A0=A0=A0 by 0x55AF8F: pthread_exit (in /lib/tls/libpthrea= d-2.3.4.so) =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D 32 bytes in 1 blocks are still reachable in loss record 6= of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x4004405: malloc (vg_replace_malloc.c:149) =3D=3D32608=3D=3D=A0=A0=A0 by 0x4005728: realloc (vg_replace_malloc.c:306) =3D=3D32608=3D=3D=A0=A0=A0 by 0x810E504: rewrite_mapper_register (in /usr/l= ibexec/slapd) =3D=3D32608=3D=3D=A0=A0=A0 by 0x3FFDE2: (below main) (in /lib/tls/libc-2.3.= 4.so) =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D 77 bytes in 5 blocks are still reachable in loss record 7= of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x4004405: malloc (vg_replace_malloc.c:149) =3D=3D32608=3D=3D=A0=A0=A0 by 0x8150E2E: ber_memalloc_x (in /usr/libexec/sl= apd) =3D=3D32608=3D=3D=A0=A0=A0 by 0x3D6363FF: ??? =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D 252 bytes in 18 blocks are definitely lost in loss record= 8 of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x4004405: malloc (vg_replace_malloc.c:149) =3D=3D32608=3D=3D=A0=A0=A0 by 0x8150E2E: ber_memalloc_x (in /usr/libexec/sl= apd) =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D 272 bytes in 2 blocks are possibly lost in loss record 9 = of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x40056BF: calloc (vg_replace_malloc.c:279) =3D=3D32608=3D=3D=A0=A0=A0 by 0x3DB71A: _dl_allocate_tls (in /lib/ld-2.3.4.= so) =3D=3D32608=3D=3D=A0=A0=A0 by 0x55A91E: pthread_create@@GLIBC_2.1 (in /lib/= tls/libpthread-2.3.4.so) =3D=3D32608=3D=3D=A0=A0=A0 by 0x811D4A9: ldap_pvt_thread_create (in /usr/li= bexec/slapd) =3D=3D32608=3D=3D=A0=A0=A0 by 0x3FFDE2: (below main) (in /lib/tls/libc-2.3.= 4.so) =3D=3D32608=3D=3D=20 =3D=3D32608=3D=3D LEAK SUMMARY: =3D=3D32608=3D=3D=A0=A0=A0 definitely lost: 280 bytes in 20 blocks. =3D=3D32608=3D=3D=A0=A0=A0=A0=A0 possibly lost: 272 bytes in 2 blocks. =3D=3D32608=3D=3D=A0=A0=A0 still reachable: 199 bytes in 10 blocks. =3D=3D32608=3D=3D=A0=A0=A0=A0=A0=A0=A0=A0 suppressed: 0 bytes in 0 blocks. My suspicious is this memory leak is happening at ber_memalloc_x (in /usr/l= ibexec/slapd). Or in the part above : =3D=3D32608=3D=3D 252 bytes in 18 blocks are definitely lost in loss record= 8 of 9 =3D=3D32608=3D=3D=A0=A0=A0 at 0x4004405: malloc (vg_replace_malloc.c:149) =3D=3D32608=3D=3D=A0=A0=A0 by 0x8150E2E: ber_memalloc_x (in /usr/libexec/sl= apd) Since right now I do not have a large number of entrances in the DB the sea= rch is easily cached in memory and the response is very quick. I will load again the DB but since this takes around 6-8hours I sent this i= nitial result from valgrind since it can already give some directions. Tomo= rrow I should send more information related with a more heavy load DB. I would like your help to see if this can identify something related with t= his memory leakage. Please let me know if I can help in this meantime with something else. Best regards, Rodrigo. --- On Sat, 12/20/08, Pierangelo Masarati <ando(a)sys-net.it> wrote: From: Pierangelo Masarati <ando(a)sys-net.it> Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 To: rlvcosta(a)yahoo.com Cc: openldap-its(a)openldap.org Date: Saturday, December 20, 2008, 7:05 PM rlvcosta(a)yahoo.com wrote: > Full_Name: Rodrigo Costa > Version: 2.4.11 > OS: RHEL4 U4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.82.161.220) >=20 >=20 > Opeldap dev team, >=20 > I'm facing an issue and after many tentatives I believe this is really a bug > that maybe could be identified and solved by openldap community. I tried to > include dmalloc into openldap 2.4.11 code but even I could compile with i= t any > tentative to execute the code generated "Segmentation Fault" so I could not use > dmalloc to identify where the memory leak is happening. Can you try with valgrind? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it ----------------------------------- =0A=0A=0A --0-1358063323-1230648878=:64021 Content-Type: text/html; charset=us-ascii <table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Pierangelo, I could run the valgrind but at this time I do not have the DB with the around 4 million subscribers. In this condition, with a small number of users, I already could see some "definitive" memory leaks and I believe they are associated with OpenLdap. Just for a history I already compiled the openldap 2.4.11 souce code without modules and TLS since many lists make reference to some possible issues in RHEL with TLS. Even so I could not have a load without the possible memory leak. So I do not believe the problems are in the RHEL libtool or glibc. In any case the result for the valgrind is (short number of entrances at this time): ==32608== Memcheck, a memory error detector. ==32608== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==32608== Using LibVEX rev 1575, a library for dynamic binary translation. ==32608== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==32608== Using valgrind-3.1.1, a dynamic binary instrumentation framework. ==32608== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==32608== For more details, rerun with: -v ==32608== ==32608== ==32608== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 86 from 2) ==32608== malloc/free: in use at exit: 751 bytes in 32 blocks. ==32608== malloc/free: 29,775 allocs, 29,743 frees, 22,150,722 bytes allocated. ==32608== For counts of detected errors, rerun with: -v ==32608== searching for pointers to 32 not-freed blocks. ==32608== checked 8,191,292 bytes. ==32608== ==32608== 16 bytes in 1 blocks are still reachable in loss record 1 of 9 ==32608==    at 0x40056BF: calloc (vg_replace_malloc.c:279) ==32608==    by 0x519364: _dlerror_run (in /lib/libdl-2.3.4.so) ==32608==    by 0x518D10: dlopen@@GLIBC_2.1 (in /lib/libdl-2.3.4.so) ==32608==    by 0x52D80D: _sasl_get_plugin (in /usr/lib/libsasl2.so.2.0.19) ==32608==    by 0x52DC61: _sasl_load_plugins (in /usr/lib/libsasl2.so.2.0.19) ==32608==    by 0x52B063: sasl_server_init (in /usr/lib/libsasl2.so.2.0.19) ==32608==    by 0x80C82C0: slap_sasl_init (in /usr/libexec/slapd) ==32608==    by 0x3FFDE2: (below main) (in /lib/tls/libc-2.3.4.so) ==32608== ==32608== ==32608== 22 bytes in 1 blocks are still reachable in loss record 2 of 9 ==32608==    at 0x4004405: malloc (vg_replace_malloc.c:149) ==32608==    by 0xB77567: (within /usr/lib/libltdl.so.3.1.0) ==32608==    by 0xB780C8: (within /usr/lib/libltdl.so.3.1.0) ==32608==    by 0xB7A79D: lt_dlsetsearchpath (in /usr/lib/libltdl.so.3.1.0) ==32608==    by 0x8068147: (within /usr/libexec/slapd) ==32608== ==32608== ==32608== 24 bytes in 1 blocks are still reachable in loss record 3 of 9 ==32608==    at 0x400579F: realloc (vg_replace_malloc.c:306) ==32608==    by 0x8151E6F: ber_bvarray_add (in /usr/libexec/slapd) ==32608==    by 0x44DD627: ??? ==32608== ==32608== ==32608== 28 bytes in 2 blocks are definitely lost in loss record 4 of 9 ==32608==    at 0x4004405: malloc (vg_replace_malloc.c:149) ==32608==    by 0xB77567: (within /usr/lib/libltdl.so.3.1.0) ==32608==    by 0xB780C8: (within /usr/lib/libltdl.so.3.1.0) ==32608==    by 0xB78CDC: (within /usr/lib/libltdl.so.3.1.0) ==32608==    by 0xB7972B: lt_dlopen (in /usr/lib/libltdl.so.3.1.0) ==32608==    by 0xB7980C: lt_dlopenext (in /usr/lib/libltdl.so.3.1.0) ==32608==    by 0x80CA1E3: module_load (in /usr/libexec/slapd) ==32608== ==32608== ==32608== 28 bytes in 1 blocks are still reachable in loss record 5 of 9 ==32608==    at 0x4004405: malloc (vg_replace_malloc.c:149) ==32608==    by 0x3D81D7: _dl_map_object_deps (in /lib/ld-2.3.4.so) ==32608==    by 0x4E7158: dl_open_worker (in /lib/tls/libc-2.3.4.so) ==32608==    by 0x3D90FD: _dl_catch_error (in /lib/ld-2.3.4.so) ==32608==    by 0x4E7CB7: _dl_open (in /lib/tls/libc-2.3.4.so) ==32608==    by 0x4E904C: do_dlopen (in /lib/tls/libc-2.3.4.so) ==32608==    by 0x3D90FD: _dl_catch_error (in /lib/ld-2.3.4.so) ==32608==    by 0x4E912D: __libc_dlopen_mode (in /lib/tls/libc-2.3.4.so) ==32608==    by 0x561087: pthread_cancel_init (in /lib/tls/libpthread-2.3.4.so) ==32608==    by 0x5611FC: _Unwind_ForcedUnwind (in /lib/tls/libpthread-2.3.4.so) ==32608==    by 0x55F020: __pthread_unwind (in /lib/tls/libpthread-2.3.4.so) ==32608==    by 0x55AF8F: pthread_exit (in /lib/tls/libpthread-2.3.4.so) ==32608== ==32608== ==32608== 32 bytes in 1 blocks are still reachable in loss record 6 of 9 ==32608==    at 0x4004405: malloc (vg_replace_malloc.c:149) ==32608==    by 0x4005728: realloc (vg_replace_malloc.c:306) ==32608==    by 0x810E504: rewrite_mapper_register (in /usr/libexec/slapd) ==32608==    by 0x3FFDE2: (below main) (in /lib/tls/libc-2.3.4.so) ==32608== ==32608== ==32608== 77 bytes in 5 blocks are still reachable in loss record 7 of 9 ==32608==    at 0x4004405: malloc (vg_replace_malloc.c:149) ==32608==    by 0x8150E2E: ber_memalloc_x (in /usr/libexec/slapd) ==32608==    by 0x3D6363FF: ??? ==32608== ==32608== ==32608== 252 bytes in 18 blocks are definitely lost in loss record 8 of 9 ==32608==    at 0x4004405: malloc (vg_replace_malloc.c:149) ==32608==    by 0x8150E2E: ber_memalloc_x (in /usr/libexec/slapd) ==32608== ==32608== ==32608== 272 bytes in 2 blocks are possibly lost in loss record 9 of 9 ==32608==    at 0x40056BF: calloc (vg_replace_malloc.c:279) ==32608==    by 0x3DB71A: _dl_allocate_tls (in /lib/ld-2.3.4.so) ==32608==    by 0x55A91E: pthread_create@@GLIBC_2.1 (in /lib/tls/libpthread-2.3.4.so) ==32608==    by 0x811D4A9: ldap_pvt_thread_create (in /usr/libexec/slapd) ==32608==    by 0x3FFDE2: (below main) (in /lib/tls/libc-2.3.4.so) ==32608== ==32608== LEAK SUMMARY: ==32608==    definitely lost: 280 bytes in 20 blocks. ==32608==      possibly lost: 272 bytes in 2 blocks. ==32608==    still reachable: 199 bytes in 10 blocks. ==32608==         suppressed: 0 bytes in 0 blocks. My suspicious is this memory leak is happening at ber_memalloc_x (in /usr/libexec/slapd). Or in the part above : ==32608== 252 bytes in 18 blocks are definitely lost in loss record 8 of 9 ==32608==    at 0x4004405: malloc (vg_replace_malloc.c:149) ==32608==    by 0x8150E2E: ber_memalloc_x (in /usr/libexec/slapd) Since right now I do not have a large number of entrances in the DB the search is easily cached in memory and the response is very quick. I will load again the DB but since this takes around 6-8hours I sent this initial result from valgrind since it can already give some directions. Tomorrow I should send more information related with a more heavy load DB. I would like your help to see if this can identify something related with this memory leakage. Please let me know if I can help in this meantime with something else. Best regards, Rodrigo. --- On Sat, 12/20/08, Pierangelo Masarati <ando(a)sys-net.it> wrote: <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Pierangelo Masarati <ando(a)sys-net.it> Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 To: rlvcosta(a)yahoo.com Cc: openldap-its(a)openldap.org Date: Saturday, December 20, 2008, 7:05 PM <pre>rlvcosta(a)yahoo.com wrote: > Full_Name: Rodrigo Costa > Version: 2.4.11 > OS: RHEL4 U4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.82.161.220) > > > Opeldap dev team, > > I'm facing an issue and after many tentatives I believe this is really a bug > that maybe could be identified and solved by openldap community. I tried to > include dmalloc into openldap 2.4.11 code but even I could compile with it any > tentative to execute the code generated "Segmentation Fault" so I could not use > dmalloc to identify where the memory leak is happening. Can you try with valgrind? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it ----------------------------------- </pre></blockquote></td></tr></table> --0-1358063323-1230648878=:64021--

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 30 Dec '08

30 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > At a quick glance, you're leaking the callback containing the cloak > response. You should remove (and free it) when called with REP_RESULT > as sr_type, and add a slap_freeself_cb() cleanup hook. You won't notice > the memory leak unless you build slapd with SLAP_NO_SL_MALLOC set, or > unless your overlay operates within a slab memory intensive context. Here is an update, I hope it addresses the concerns you raised: ftp://ftp.openldap.org/incoming/manu-cloak-20081230.c -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5875) sparc64/gcc-3.3 build fix
by Kurt＠OpenLDAP.org 29 Dec '08

29 Dec '08

On Dec 28, 2008, at 4:52 PM, kurt(a)openldap.org wrote: > On a technical note, use of platform macros (sun and gcc versions) > should be avoided. Instead, autoconf should be used to detect > conditions for need to be adapted for. > > On an IPR review, I suspect it would be easier to update to: > http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/hash/sha1.c?rev=1.21;con… > > then to try to identify the contributors and get their "okay". I should note that, from a technical point of view, it might also be better to integrate the latest from OpenBSD. This would hopefully provide a SHA1 implementation which works on more platforms than the current version, or the current version as modified by Klaus's patch. -- Kurt

1 0

Fwd: (ITS#5875) sparc64/gcc-3.3 build fix
by Kurt＠OpenLDAP.org 29 Dec '08

29 Dec '08

For Klaus's benefit. Begin forwarded message: > From: Kurt Zeilenga <Kurt(a)OpenLDAP.org> > Date: December 29, 2008 11:01:08 AM PST > To: manu(a)netbsd.org > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#5875) sparc64/gcc-3.3 build fix > > > On Dec 28, 2008, at 10:37 PM, manu(a)netbsd.org wrote: > >> Howard Chu <hyc(a)symas.com> wrote: >> >>>> NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a >>>> build >>>> problem on sparc64 with gcc 3.x (x<= 3). The build failure is >>>> caused by >>>> a bug in gcc. >>>> >>>> I think it would not hurt to commit this patch in OpenLDAP CVS: >>>> everything is guarded by macros, so it cannot cause any harm to >>>> unaffected systems, and the workaround has been tested by NetBSD >>>> people >>>> for 5 years. >>> >>> Kurt will probably have something to say about this too - this is >>> more than a >>> couple-line patch, it needs to be submitted by its original >>> author, with >>> appropriate rights attributions etc. >> >> Klaus Klein <kleink(a)kleink.org> is the contributor (I added him to >> the >> recipients of this messages). >> >> Do we need anything more than an e-mail with the patch and the >> excerpt >> below correctly filled? >> >> "This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by <YOUR NAME> <YOUR-EMAIL-ADDRESS>. I >> have not >> assigned rights and/or interest in this work to any party. " > > One would also need an appropriate "rights statement". See http://www.openldap.org/devel/contributing.html > . > > -- Kurt

1 0

Re: (ITS#5875) sparc64/gcc-3.3 build fix
by Kurt＠OpenLDAP.org 29 Dec '08

29 Dec '08

On Dec 28, 2008, at 10:37 PM, manu(a)netbsd.org wrote: > Howard Chu <hyc(a)symas.com> wrote: > >>> NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a >>> build >>> problem on sparc64 with gcc 3.x (x<= 3). The build failure is >>> caused by >>> a bug in gcc. >>> >>> I think it would not hurt to commit this patch in OpenLDAP CVS: >>> everything is guarded by macros, so it cannot cause any harm to >>> unaffected systems, and the workaround has been tested by NetBSD >>> people >>> for 5 years. >> >> Kurt will probably have something to say about this too - this is >> more than a >> couple-line patch, it needs to be submitted by its original author, >> with >> appropriate rights attributions etc. > > Klaus Klein <kleink(a)kleink.org> is the contributor (I added him to the > recipients of this messages). > > Do we need anything more than an e-mail with the patch and the excerpt > below correctly filled? > > "This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by <YOUR NAME> <YOUR-EMAIL-ADDRESS>. I have > not > assigned rights and/or interest in this work to any party. " One would also need an appropriate "rights statement". See http://www.openldap.org/devel/contributing.html . -- Kurt

1 0

Re: (ITS#5872) slapo-cloak
by hyc＠symas.com 29 Dec '08

29 Dec '08

ando(a)sys-net.it wrote: > michael(a)stroeder.com wrote: >> ando(a)sys-net.it wrote: >>> Hallvard B Furuseth wrote: >>>> ando(a)sys-net.it writes: >>>>> On a related note, if this can be considered of general usefulness, LDAP >>>>> specs would need to be changed in order to define a finer grain of >>>>> attribute request; something like: >>>>> >>>>> empty or "*" ; all user, except attrs that need to be explicitly req. >>>>> "+" ; all operational >>>>> <all including attrs that need to be explicitly requested> >>>>> <...> >>>> Would it be cleaner if slapo-cloak redefines the attributes to be >>>> operational, or to behave as if they are? Maybe give them an >>>> X-AS-OPERATIONAL extension? Or would that just mess up schema code, >>>> things like attribute inheritance? >>> I think things would mess up. >> I'd also recommend *not* to turn user attribute types into operational >> attribute types. This would certainly confuse schema-aware clients. >> >>> Moreover, I see a number of features system administrators could ask >>> for; e.g. hide attributes only when matching a URI (base, scope, >>> filter), >> Well, that's something many overlays would benefit from. > > In fact, based on recent modifications to slapo-constraint(5) and other > overlays, I'm considering the opportunity to introduce generic helpers > to parse and check this type of generic limitations. We've discussed this before - overlays ought to have a configurable range of effect, using an X.500 Subtree Search Specification. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 29 Dec '08

29 Dec '08

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> Hallvard B Furuseth wrote: >>> ando(a)sys-net.it writes: >>>> On a related note, if this can be considered of general usefulness, LDAP >>>> specs would need to be changed in order to define a finer grain of >>>> attribute request; something like: >>>> >>>> empty or "*" ; all user, except attrs that need to be explicitly req. >>>> "+" ; all operational >>>> <all including attrs that need to be explicitly requested> >>>> <...> >>> Would it be cleaner if slapo-cloak redefines the attributes to be >>> operational, or to behave as if they are? Maybe give them an >>> X-AS-OPERATIONAL extension? Or would that just mess up schema code, >>> things like attribute inheritance? >> I think things would mess up. > > I'd also recommend *not* to turn user attribute types into operational > attribute types. This would certainly confuse schema-aware clients. > >> Moreover, I see a number of features system administrators could ask >> for; e.g. hide attributes only when matching a URI (base, scope, >> filter), > > Well, that's something many overlays would benefit from. In fact, based on recent modifications to slapo-constraint(5) and other overlays, I'm considering the opportunity to introduce generic helpers to parse and check this type of generic limitations. > >> or based on size limit, I meant: size of the attribute; only return values whose size does not exceed a gien number of octets, unless explicitly requested. > ??? > >> or based on client's identity and so. > > That would be similar (not equal) to using ACLs. That was explicitly not > the case in the original inquiry. Not exactly. We're discussing the issue of limiting what information not explicitly requested should be returned. An administrator could decide, say, that anonymous will not get any jpegPhoto, unless explicitly requested. This is not ACL (in the stricter sense of what access privilege an identity is granted), but rather resource access policy. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by michael＠stroeder.com 29 Dec '08

29 Dec '08

ando(a)sys-net.it wrote: > Hallvard B Furuseth wrote: >> ando(a)sys-net.it writes: >>> On a related note, if this can be considered of general usefulness, LDAP >>> specs would need to be changed in order to define a finer grain of >>> attribute request; something like: >>> >>> empty or "*" ; all user, except attrs that need to be explicitly req. >>> "+" ; all operational >>> <all including attrs that need to be explicitly requested> >>> <...> >> Would it be cleaner if slapo-cloak redefines the attributes to be >> operational, or to behave as if they are? Maybe give them an >> X-AS-OPERATIONAL extension? Or would that just mess up schema code, >> things like attribute inheritance? > > I think things would mess up. I'd also recommend *not* to turn user attribute types into operational attribute types. This would certainly confuse schema-aware clients. > Moreover, I see a number of features system administrators could ask > for; e.g. hide attributes only when matching a URI (base, scope, > filter), Well, that's something many overlays would benefit from. > or based on size limit, ??? > or based on client's identity and so. That would be similar (not equal) to using ACLs. That was explicitly not the case in the original inquiry. Ciao, Michael.

1 0

Re: (ITS#5876) Build fix: ODBC
by manu＠netbsd.org 29 Dec '08

29 Dec '08

Erratum: please consider ftp://ftp.openldap.org/incoming/manu-odbc-20081229.patch.1 instead of that one, which is broken: ftp://ftp.openldap.org/incoming/manu-odbc-20081229.patch -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5875) sparc64/gcc-3.3 build fix
by manu＠netbsd.org 29 Dec '08

29 Dec '08

Howard Chu <hyc(a)symas.com> wrote: > > NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a build > > problem on sparc64 with gcc 3.x (x<= 3). The build failure is caused by > > a bug in gcc. > > > > I think it would not hurt to commit this patch in OpenLDAP CVS: > > everything is guarded by macros, so it cannot cause any harm to > > unaffected systems, and the workaround has been tested by NetBSD people > > for 5 years. > > Kurt will probably have something to say about this too - this is more than a > couple-line patch, it needs to be submitted by its original author, with > appropriate rights attributions etc. Klaus Klein <kleink(a)kleink.org> is the contributor (I added him to the recipients of this messages). Do we need anything more than an e-mail with the patch and the excerpt below correctly filled? "This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by <YOUR NAME> <YOUR-EMAIL-ADDRESS>. I have not assigned rights and/or interest in this work to any party. " -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#5876) Build fix: ODBC
by manu＠netbsd.org 29 Dec '08

29 Dec '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD-4.0 URL: ftp://ftp.openldap.org/incoming/manu-odbc-20081229.patch Submission from: (NULL) (213.41.141.172) In unixODBC and iODBC, SQL_NO_DATA_FOUND was turned into SQL_NO_DATA, starting with ODBC 3.0. Supporting older ODBC package is easy, we just have to test both macros, as in the attached patch. This is an cleanup from a 3 years old patch that has been available in NetBSD package system.

1 0

Re: (ITS#5875) sparc64/gcc-3.3 build fix
by Kurt＠OpenLDAP.org 29 Dec '08

29 Dec '08

On Dec 28, 2008, at 4:10 PM, hyc(a)symas.com wrote: > manu(a)netbsd.org wrote: >> Full_Name: Emmanuel Dreyfus >> Version: HEAD >> OS: NetBSD-4.0 >> URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/ >> databases/openldap/patches/patch-ad?rev=1.7 >> Submission from: (NULL) (213.41.141.172) >> >> >> NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a >> build problem on >> sparc64 with gcc 3.x (x<= 3). The build failure is caused by a bug >> in gcc. >> >> I think it would not hurt to commit this patch in OpenLDAP CVS: >> everything is >> guarded by macros, so it cannot cause any harm to unaffected >> systems, and the >> workaround has been tested by NetBSD people for 5 years. > > Kurt will probably have something to say about this too - this is > more than a > couple-line patch, it needs to be submitted by its original author, > with > appropriate rights attributions etc. On a technical note, use of platform macros (sun and gcc versions) should be avoided. Instead, autoconf should be used to detect conditions for need to be adapted for. On an IPR review, I suspect it would be easier to update to: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/hash/sha1.c?rev=1.21;con… then to try to identify the contributors and get their "okay". -- Kurt

1 0

Re: (ITS#5875) sparc64/gcc-3.3 build fix
by hyc＠symas.com 29 Dec '08

29 Dec '08

manu(a)netbsd.org wrote: > Full_Name: Emmanuel Dreyfus > Version: HEAD > OS: NetBSD-4.0 > URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/databases/openldap/pa… > Submission from: (NULL) (213.41.141.172) > > > NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a build problem on > sparc64 with gcc 3.x (x<= 3). The build failure is caused by a bug in gcc. > > I think it would not hurt to commit this patch in OpenLDAP CVS: everything is > guarded by macros, so it cannot cause any harm to unaffected systems, and the > workaround has been tested by NetBSD people for 5 years. Kurt will probably have something to say about this too - this is more than a couple-line patch, it needs to be submitted by its original author, with appropriate rights attributions etc. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 28 Dec '08

28 Dec '08

manu(a)netbsd.org wrote: > Howard Chu <hyc(a)symas.com> wrote: > >> I suppose so. I put my stuff in there when I don't consider it worth my effort >> to autoconf-iscate it. Things like nssov only work with Linux, so there's no >> point in adding the overhead. Stuff in there really is of too limited use to >> warrant the full effort of maintenance that the core code gets. > > That means the added value of contrib/ is that it will only be > maintained by its contributor and will rot otherwise. > > Overlays that have been autoconf-ified could all reside in > server/slapd/overlays. Non-core thing would be disabled by default, and > would rot if not maintained by their contributors, as they are now... Didn't mean to start a holy war about contrib/ vs. overlays/. My intention was to isolate overlay development from autoconf-ing, until generality and usefulness demand for moving to overlays/. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 28 Dec '08

28 Dec '08

Hallvard B Furuseth wrote: > ando(a)sys-net.it writes: >> On a related note, if this can be considered of general usefulness, LDAP >> specs would need to be changed in order to define a finer grain of >> attribute request; something like: >> >> empty or "*" ; all user, except attrs that need to be explicitly req. >> "+" ; all operational >> <all including attrs that need to be explicitly requested> >> <...> > > Would it be cleaner if slapo-cloak redefines the attributes to be > operational, or to behave as if they are? Maybe give them an > X-AS-OPERATIONAL extension? Or would that just mess up schema code, > things like attribute inheritance? I think things would mess up. The X-AS-OPERATIONAL could help, although it would result in a modification of otherwise standard-track schema items. Moreover, I see a number of features system administrators could ask for; e.g. hide attributes only when matching a URI (base, scope, filter), or based on size limit, or based on client's identity and so. In this case, I'd keep schema out. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5875) sparc64/gcc-3.3 build fix
by manu＠netbsd.org 28 Dec '08

28 Dec '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD-4.0 URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/databases/openldap/pa… Submission from: (NULL) (213.41.141.172) NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a build problem on sparc64 with gcc 3.x (x <= 3). The build failure is caused by a bug in gcc. I think it would not hurt to commit this patch in OpenLDAP CVS: everything is guarded by macros, so it cannot cause any harm to unaffected systems, and the workaround has been tested by NetBSD people for 5 years.

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Howard Chu <hyc(a)symas.com> wrote: > I suppose so. I put my stuff in there when I don't consider it worth my effort > to autoconf-iscate it. Things like nssov only work with Linux, so there's no > point in adding the overhead. Stuff in there really is of too limited use to > warrant the full effort of maintenance that the core code gets. That means the added value of contrib/ is that it will only be maintained by its contributor and will rot otherwise. Overlays that have been autoconf-ified could all reside in server/slapd/overlays. Non-core thing would be disabled by default, and would rot if not maintained by their contributors, as they are now... -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5872) slapo-cloak
by hyc＠symas.com 27 Dec '08

27 Dec '08

manu(a)netbsd.org wrote: > Pierangelo Masarati<ando(a)sys-net.it> wrote: > >> I'd see this overlay more appropriate for contrib/slapd-modules right >> now, until its functionality is considered of general usefulness, which >> doesn't seem to be the case right now. > > Do you think an overlay in the contrib directory could have its --enable > flag in top level configure? > My feeling about the contrib directory is that it is some kind of evil > swamp where things are much more difficult to automatically build for > inclusion in a package. I suppose so. I put my stuff in there when I don't consider it worth my effort to autoconf-iscate it. Things like nssov only work with Linux, so there's no point in adding the overhead. Stuff in there really is of too limited use to warrant the full effort of maintenance that the core code gets. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5872) slapo-cloak
by hyc＠symas.com 27 Dec '08

27 Dec '08

ando(a)sys-net.it wrote: > Emmanuel Dreyfus wrote: >> Pierangelo Masarati<ando(a)sys-net.it> wrote: >> >>> That's my opinion, of course. I suggest you start from contrib/ and >>> then we'll vote for moving it to overlays/. >> How do I book an OID for the config database, for an overlay in contrib? >> Is it ok to just keep the comment in servers/slapd/bconfig.c? >> * OLcfgOv{Oc|At}:22 -> cloak > > Yes. Why did you skip :21, BTW? No, for contrib modules reserve the OID in contrib/ConfigOIDs -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Also, you shouldn't duplicate the entry until you find an occurrence of an attribute that needs to be hidden, otherwise you make slapo-cloak unnecessarily resource intensive. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

manu(a)netbsd.org wrote: > Pierangelo Masarati <ando(a)sys-net.it> wrote: > >>> How do I book an OID for the config database, for an overlay in contrib? >>> Is it ok to just keep the comment in servers/slapd/bconfig.c? >>> * OLcfgOv{Oc|At}:22 -> cloak >> Yes. Why did you skip :21, BTW? > > Can't remeber why. I'll go back to 21. At a quick glance, you're leaking the callback containing the cloak response. You should remove (and free it) when called with REP_RESULT as sr_type, and add a slap_freeself_cb() cleanup hook. You won't notice the memory leak unless you build slapd with SLAP_NO_SL_MALLOC set, or unless your overlay operates within a slab memory intensive context. Configuration is leaking as well, I couldn't exactly trace where. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > > How do I book an OID for the config database, for an overlay in contrib? > > Is it ok to just keep the comment in servers/slapd/bconfig.c? > > * OLcfgOv{Oc|At}:22 -> cloak > Yes. Why did you skip :21, BTW? Can't remeber why. I'll go back to 21. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Kurt Zeilenga wrote: > > On Dec 27, 2008, at 2:46 AM, ando(a)sys-net.it wrote: > >> empty or "*" ; all user, except attrs that need to be explicitly req. >> "+" ; all operational >> <all including attrs that need to be explicitly requested> >> <...> > > I note that the specification of '+' does allow a server not to provide > all operational attributes. That is, a server is allowed to only return > some operational attributes when requested by name. ... based on how expensive their computation is. In fact, we do not exploit this too much in slapd(8), where '+' usually triggers operational all attributes evaluation. Probably, we should add the possibility to configure whether the most expensive are computed or not when not explicitly requested. > This is not so with '*' (or empty list). well, according to RFC4511, Section 4.5.1.8.: Client implementors should note that even if all user attributes are requested, some attributes and/or attribute values of the entry may not be included in Search results due to access controls or other restrictions. The restrictions we're discussing may well fit into this. > However, that said, I see no > particular issue with a server choosing to return a particular user > applications attribute only when requested by name. I see this simply > as an administrative restriction... and those are always allowed. Exactly. > (I also note that use of '*' (or empty list) and '+' should generally be > limited to requests formed by a human. It is bad (but all to common) > practice for application-specific directory clients to ask for > everything. They should really only ask for what they are prepared to > make use of. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by Kurt＠OpenLDAP.org 27 Dec '08

27 Dec '08

On Dec 27, 2008, at 2:46 AM, ando(a)sys-net.it wrote: > empty or "*" ; all user, except attrs that need to be explicitly req. > "+" ; all operational > <all including attrs that need to be explicitly requested> > <...> I note that the specification of '+' does allow a server not to provide all operational attributes. That is, a server is allowed to only return some operational attributes when requested by name. This is not so with '*' (or empty list). However, that said, I see no particular issue with a server choosing to return a particular user applications attribute only when requested by name. I see this simply as an administrative restriction... and those are always allowed. (I also note that use of '*' (or empty list) and '+' should generally be limited to requests formed by a human. It is bad (but all to common) practice for application-specific directory clients to ask for everything. They should really only ask for what they are prepared to make use of. -- Kurt

1 0

(ITS#5874) MMR does not work in refreshOnly
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando After updating tests/run.in from CVS (rev 1.59) and reconfiguring, executing test050 with SYNCMODE=ro results in a failure. The failure is not strictly reproducible, but it always occurred to me, either affecting one or another delete that is not propagated to all participants to the MMR pool. I've raised the sleep time, to make sure there's no chance replication did not occur yet. I wonder if refreshOnly makes any sense for a MMR pool. If it doesn't, it should not be allowed. If it does, deletes should be replicated correctly. p.

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Emmanuel Dreyfus wrote: > Pierangelo Masarati <ando(a)sys-net.it> wrote: > >> That's my opinion, of course. I suggest you start from contrib/ and >> then we'll vote for moving it to overlays/. > > How do I book an OID for the config database, for an overlay in contrib? > Is it ok to just keep the comment in servers/slapd/bconfig.c? > * OLcfgOv{Oc|At}:22 -> cloak Yes. Why did you skip :21, BTW? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > That's my opinion, of course. I suggest you start from contrib/ and > then we'll vote for moving it to overlays/. How do I book an OID for the config database, for an overlay in contrib? Is it ok to just keep the comment in servers/slapd/bconfig.c? * OLcfgOv{Oc|At}:22 -> cloak -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > It is :). However, I think only generally useful things should go into > mainstream. As such, I remember some overlays moving from overlays/ to > slapd-modules/ and others moving the other way, based on their > generality and usefulness. The annoying thing is that the only added value of contrib/ is to make building more difficult. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Emmanuel Dreyfus wrote: >> I'd see this overlay more appropriate for contrib/slapd-modules right >> now, until its functionality is considered of general usefulness, which >> doesn't seem to be the case right now. > > Do you think an overlay in the contrib directory could have its --enable > flag in top level configure? > > My feeling about the contrib directory is that it is some kind of evil > swamp where things are much more difficult to automatically build for > inclusion in a package. It is :). However, I think only generally useful things should go into mainstream. As such, I remember some overlays moving from overlays/ to slapd-modules/ and others moving the other way, based on their generality and usefulness. For example, smbk5pwd should be in overlays/, given its usefulness, but it is probably not general enough. Yours is general (i.e. not tied to a specific architecture or interoperation issue), but probably of limited usefulness (how many users would actually need it?). That's my opinion, of course. I suggest you start from contrib/ and then we'll vote for moving it to overlays/. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > I'd see this overlay more appropriate for contrib/slapd-modules right > now, until its functionality is considered of general usefulness, which > doesn't seem to be the case right now. Do you think an overlay in the contrib directory could have its --enable flag in top level configure? My feeling about the contrib directory is that it is some kind of evil swamp where things are much more difficult to automatically build for inclusion in a package. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#5873) slapd(8) does not mention sid in -c option value
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Slapd(8)'s -c option allows to set the replication cookie to start replication with. Currently it states that valid name/value pairs are rid and csn; however, 2.4 allows sid as well, in multi-master/mirror-mode replication agreements. Not sure whether setting any sid in this cookie makes any sense, but the man page should note it for clarity and completeness. p.

1 0

Re: (ITS#5868) failed assertion with back-relay
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Guillaume.Rousse(a)inria.fr wrote: > Full_Name: Guillaume Rousse > Version: 2.4.12 > OS: Mandriva linux > URL: > Submission from: (NULL) (193.55.250.67) Can't reproduce with HEAD or 2.4.12; you need to provide more details: a minimal slapd.conf, a minimal ldif and the exact operation that fails. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

manu(a)netbsd.org wrote: > The cloak overlay to slapd(8) allows the server to hide specific > attributes, unless explicitely requested by the client. This improve > performance when a client requests all attributes and get a huge binary > attribute that is of no interest for it (think jpegPhoto) I'd see this overlay more appropriate for contrib/slapd-modules right now, until its functionality is considered of general usefulness, which doesn't seem to be the case right now. On a related note, if this can be considered of general usefulness, LDAP specs would need to be changed in order to define a finer grain of attribute request; something like: empty or "*" ; all user, except attrs that need to be explicitly req. "+" ; all operational <all including attrs that need to be explicitly requested> <...> p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5872) slapo-cloak
by manu＠netbsd.org 25 Dec '08

25 Dec '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD-4.0 URL: ftp://ftp.openldap.org/incoming/manu-cloak-20081225.patch Submission from: (NULL) (213.41.141.172) The cloak overlay to slapd(8) allows the server to hide specific attributes, unless explicitely requested by the client. This improve performance when a client requests all attributes and get a huge binary attribute that is of no interest for it (think jpegPhoto)

1 0

(ITS#5868) failed assertion with back-relay
by Guillaume.Rousse＠inria.fr 22 Dec '08

22 Dec '08

Full_Name: Guillaume Rousse Version: 2.4.12 OS: Mandriva linux URL: Submission from: (NULL) (193.55.250.67) Here's my back-relay configuration: database relay suffix ou=telephony,dc=msr-inria,dc=inria,dc=fr overlay rwm rwm-suffixmassage ou=users,dc=msr-inria,dc=inria,dc=fr rwm-map attribute telephoneNumber homePhone rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute uid * rwm-map attribute * access to dn.subtree="ou=telephony,dc=msr-inria,dc=inria,dc=fr" by * read The server crashes immediatly when attempting a query for given prefix. Here is debug trace: slap_listener_activate(7): >>> slap_listener(ldap:///) connection_get(17): got connid=0 connection_read(17): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 12 contents: ber_get_next conn=0 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: version=3 dn="" method=128 send_ldap_result: conn=0 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 17 do_bind: v3 anonymous bind connection_get(17): got connid=0 connection_read(17): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 77 contents: ber_get_next conn=0 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <ou=telephony,dc=msr-inria,dc=inria,dc=fr> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: ==> limits_get: conn=0 op=1 dn="[anonymous]" ==> rewrite_context_apply [depth=1] string='ou=telephony,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=telephony,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='ou=telephony,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ou=users,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <ou=users,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <ou=users,dc=msr-inria,dc=inria,dc=fr>, <ou=users,dc=msr-inria,dc=inria,dc=fr> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' ==> rewrite_context_apply [depth=1] res={0,'NULL'} put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ber_scanf fmt (m) ber: => bdb_search bdb_dn2entry("ou=users,dc=msr-inria,dc=inria,dc=fr") => bdb_dn2id("ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2id: got id=0x2 entry_decode: "ou=users,dc=msr-inria,dc=inria,dc=fr" <= entry_decode(ou=users,dc=msr-inria,dc=inria,dc=fr) search_candidates: base="ou=users,dc=msr-inria,dc=inria,dc=fr" (0x00000002) scope=2 => bdb_dn2idl("ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2idl: id=90 first=2 last=190 => bdb_presence_candidates (objectClass) bdb_search_candidates: id=90 first=2 last=190 ==> rewrite_context_apply [depth=1] string='ou=users,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=users,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='ou=users,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'ou=telephony,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <ou=telephony,dc=msr-inria,dc=inria,dc=fr> => send_search_entry: conn 0 dn="ou=telephony,dc=msr-inria,dc=inria,dc=fr" ber_flush2: 93 bytes to sd 17 <= send_search_entry: conn 0 exit. entry_decode: "uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr" <= entry_decode(uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr) => bdb_dn2id("uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2id: got id=0x4 ==> rewrite_context_apply [depth=1] string='uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=users,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr> => send_search_entry: conn 0 dn="uid=ingleber,ou=telephony,dc=msr-inria,dc=inria,dc=fr" ber_flush2: 229 bytes to sd 17 <= send_search_entry: conn 0 exit. entry_decode: "uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr" <= entry_decode(uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr) => bdb_dn2id("uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr") <= bdb_dn2id: got id=0x6 ==> rewrite_context_apply [depth=1] string='uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr' ==> rewrite_rule_apply rule='((.+),)?ou=users,[ ]?dc=msr-inria,[ ]?dc=inria,[ ]?dc=fr$' string='uid=fmorin,ou=users,dc=msr-inria,dc=inria,dc=fr' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr'} >>> dnPrettyNormal: <uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr> <<< dnPrettyNormal: <uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr>, <uid=fmorin,ou=telephony,dc=msr-inria,dc=inria,dc=fr> => send_search_entry: conn 0 dn="(null)" slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' failed I'm running openldap 2.4.12 (official mandriva package) under mandriva x86_64.

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 22 Dec '08

22 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-26328-1229943475-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 'HEAD' I get the following: ./slapd -h "ldap:///" slapo-ppolicy cannot be global Seems like a decent solution Thanks --=20 Mark Janssen Visit HAR2009, the four-yearly Dutch outdoor technology-conference August 13-16, 2009, vierhouten. http://www.har2009.org --=_server11-26328-1229943475-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklPcrIACgkQb6urvDV9IXhs4gCeM0FRAXrZ1NKGZn5V3w9Igs07 STMAn1zn7owuM9xj5K7+YdR3QGUhEWGo =8U9N -----END PGP SIGNATURE----- --=_server11-26328-1229943475-0001-2--

1 0

Re: (ITS#5861) Assert control on Add request fails
by ando＠sys-net.it 20 Dec '08

20 Dec '08

Kurt Zeilenga wrote: > This is not to say slapd(8) shouldn't be updated to make use of the > control when provided with Add requests, just saying it's technically > okay that it doesn't. Slapd(8) has been updated. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5867) back-config does not return sizeLimitExceeded
by ando＠sys-net.it 20 Dec '08

20 Dec '08

h.b.furuseth(a)usit.uio.no wrote: > back-config obeys sizelimit, but returns success instead of sizeLimitExceeded. should be fixed in HEAD, please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5861) Assert control on Add request fails
by Kurt＠OpenLDAP.org 20 Dec '08

20 Dec '08

On Dec 20, 2008, at 12:13 PM, ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> RFC 4528 says the Assert control is appropriate for Add. Yes. >> Slapd disagrees: No. slapd(8) is saying the control is unavailable. That's quite different than saying it is inappropriate. >> >> >> $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)' >> <test.ldif >> adding new entry "o=test" >> ldap_add: Critical extension is unavailable (12) >> additional info: critical extension is unavailable > > According to this thread > > <http://www.openldap.org/lists/openldap-software/200512/msg00250.html> > > the author of the assertion control (Kurt :) believes the current > specification is flawed. In fact, the assertion control is intended > to > apply to the contents of the DIT. The entry does not belong to the > DIT > until the operation is completed, so assertion cannot apply. Those comments were in respect to the I-D (when it was a work in progress). The specification does allow for the control to be attached to Add requests. Though it might seem kind of pointless, a client might do it as it is not itself capable of evaluating some assertion. I would argue that it fine for a server which cannot handle the control in this (or other cases) to return unavailableCriticalExtension. The specification certainly doesn't require a server to make use of the control in cases where it might be asserted. This is not to say slapd(8) shouldn't be updated to make use of the control when provided with Add requests, just saying it's technically okay that it doesn't.

1 0

Re: (ITS#5863) assertion failed in ber_bvreplace_x() with translucent overlay
by ando＠sys-net.it 20 Dec '08

20 Dec '08

guillaume.pujol(a)eds.com wrote: > idassert-bind bindmethod=simple mode=self This line makes no sense. In fact, it assumes an empty DN ("anonymous") can authorize users. This idassert-bind statement should be invalid. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5860) slapd memeory leak under openldap 2.4
by ando＠sys-net.it 20 Dec '08

20 Dec '08

rlvcosta(a)yahoo.com wrote: > Full_Name: Rodrigo Costa > Version: 2.4.11 > OS: RHEL4 U4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.82.161.220) > > > Opeldap dev team, > > I'm facing an issue and after many tentatives I believe this is really a bug > that maybe could be identified and solved by openldap community. I tried to > include dmalloc into openldap 2.4.11 code but even I could compile with it any > tentative to execute the code generated "Segmentation Fault" so I could not use > dmalloc to identify where the memory leak is happening. Can you try with valgrind? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by ando＠sys-net.it 20 Dec '08

20 Dec '08

A workaround is in HEAD. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5861) Assert control on Add request fails
by ando＠sys-net.it 20 Dec '08

20 Dec '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > RFC 4528 says the Assert control is appropriate for Add. Slapd disagrees: > > $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)' <test.ldif > adding new entry "o=test" > ldap_add: Critical extension is unavailable (12) > additional info: critical extension is unavailable According to this thread <http://www.openldap.org/lists/openldap-software/200512/msg00250.html> the author of the assertion control (Kurt :) believes the current specification is flawed. In fact, the assertion control is intended to apply to the contents of the DIT. The entry does not belong to the DIT until the operation is completed, so assertion cannot apply. > back-bdb and back-sql do not apply the assert control to Add. As per what seems to be the intention of the author of the specification (although it is in contrast with the current specification, RFC4528). > The message comes from slapd/controls.c. Don't fix that before fixing > Add in the backends, otherwise critical controls can be ignored. > > Another strangeness: overlays/syncprov.c applies the Assert control to > Compare but not other operations. I don't know why, there are no > comments about it. No clue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs