- openldap-bugs - openldap.org

(ITS#7337) libmdb can corrupt when reaching maxsize
by hyc＠OpenLDAP.org 26 Jul '12

26 Jul '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.97.21) Submitted by: hyc Already fixed by commit 234cd9dfb54ef2f7f83963d95b6eb8e9735bb372 If the DB maxsize was reached while pruning consumed records from the free list inside mdb_txn_commit, the error was ignored. As a result the txn_commit would return success even though it only partly succeeded. The code is now fixed to abort the txn and return the error code.

1 0

Re: (ITS#7335) Error in slapo-refint man page
by hyc＠symas.com 25 Jul '12

25 Jul '12

riggs(a)umn.edu wrote: > Full_Name: Benjamin Riggs > Version: 2.4.23 > OS: http://ftp.scientificlinux.org/linux/scientific/6x/i386/os/Packages/openlda… > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.101.155.71) > > > The slapo-refint man page has only documentation for slapd.conf, not > slapd-config. Normally this wouldn't be a problem, but the configuration > keywords are not the usual map of simply adding 'olc': > > refint_attributes is changed to olcRefintAttribute (no 's'!) > refint_nothing is changed to olcRefintNothing > refint_modifiersname is changed to olcRefintModifiersName That's true. All of the manpages should be updated for cn=config. In that respect this ITS can be combined with ITS#7288. However, we need to decide on how the new information will be presented, to avoid any unnecessary duplication. It's already quite redundant to maintain both the cn=config and slapd.conf chapters of the Admin Guide. Also, the overall issue is an extremely low priority, since all of the schema definitions can simply be read out of the cn=schema,cn=config entry. The slapd-config(5) manpage and Admin Guide already note that all of the schema are present here, so anyone looking for this information should already know to look there. -- -- 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#7225) back-monitor/ldap crash in test020-proxycache
by ondrej.kuznik＠acision.com 25 Jul '12

25 Jul '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have noticed the ITS has not been updated after Pierangelo commited ce54dabb1b69c5b310cfc4ff689bc339f3256e22 and still lists this ITS as broken. Currently back-ldap in master is buildable and passes the relevant tests in the test suite and my manual tests. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAQFJIACgkQ9GWxeeH+cXtjgACcDdbtxso5VaK6OjwZ2CsQETTf kR8AniMzHr3uCExS5JugvmRCI5F14RCi =EloX -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

Re: (ITS#7182) back-ldap monitoring improvements
by ondrej.kuznik＠acision.com 25 Jul '12

25 Jul '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/07/2012 12:52 PM, h.b.furuseth(a)usit.uio.no wrote: > Howard Chu wrote: >> Also, you're using monitor_entry_stub() directly in the back-ldap >> code. It is forbidden for modules to directly reference each >> other's symbols. If you need this function, add it to >> monitor_extra_t first and call it through there. > > Thus, currently './configure --enable-ldap --disable-monitor' does > not compile in master. I have noticed the ITS has not been updated after Pierangelo commited 11acc75e9ff31ae52b3b8c94b63189b51a764c01 and still lists this ITS as broken. Currently back-ldap in master is buildable and passes the relevant tests in the test suite and my manual tests. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAQFCAACgkQ9GWxeeH+cXshQwCdHRGaMyIOCKQk1jVhZ+S40b9R Hl8Ani1snr8svKOInMCEWL69l6EzNRHW =1RuS -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

Re: (ITS#7336) Ldapmodify crashes slapd when updating olcTLSVerifyClient attribute via TLS authentication
by quanah＠zimbra.com 25 Jul '12

25 Jul '12

--On Wednesday, July 25, 2012 12:26 PM +0000 martin.bozic(a)gmail.com wrote: > Full_Name: Martin Bozic > Version: 2.4.23 > OS: CentOS 6.3 > URL: http://pastebin.com/hkPEcBgw > Submission from: (NULL) (2001:1470:f800::370) When filing a bug report, please use the latest version of OpenLDAP, otherwise your report is likely to be ignored. Particularly in this case, given the antiquity of 2.4.23. I would note that there have been numerous, significant fixes to the MozNSS support in OpenLDAP, which is what RHEL chose to link OpenLDAP to instead of the more stable OpenSSL. You may want to look at using saner packages, such as <http://ltb-project.org/wiki/download> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7336) Ldapmodify crashes slapd when updating olcTLSVerifyClient attribute via TLS authentication
by martin.bozic＠gmail.com 25 Jul '12

25 Jul '12

Full_Name: Martin Bozic Version: 2.4.23 OS: CentOS 6.3 URL: http://pastebin.com/hkPEcBgw Submission from: (NULL) (2001:1470:f800::370) Hello, I've come across a bug that it's not critical but bug none the less. When I'm trying to modify olcTLSVerifyClient via ldapmodify slapd crashes (segmentation fault). Via EXTERNAL everything works without a hitch: ldapmodify -Y EXTERNAL -H ldapi:/// << EOF dn: cn=config changetype: modify replace: olcTLSVerifyClient olcTLSVerifyClient: demand EOF Via TLS connection slapd crashes: ldapmodify -x -H ldaps://ldap.test.com -D cn=admin,cn=config -W << EOF dn: cn=config changetype: modify replace: olcTLSVerifyClient olcTLSVerifyClient: never EOF Configuration in cn=config: dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: /usr/share/openldap-servers/slapd.conf.obsolete olcConfigDir: /etc/openldap/slapd.d/ olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcDisallows: bind_anon olcGentleHUP: FALSE olcIdleTimeout: 30 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 128 olcLogLevel: config stats shell filter olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSaslSecProps: noanonymous,noplain olcSecurity: ssf=128 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificateFile: /etc/openldap/cacerts/ca.crt olcTLSCACertificatePath: /etc/openldap/certs olcTLSCertificateFile: /etc/openldap/cacerts/slapd.crt olcTLSCertificateKeyFile: /etc/openldap/cacerts/slapd.key olcTLSCipherSuite: HIGH:MEDIUM:-SSLv2 olcTLSVerifyClient: never olcToolThreads: 1 olcWriteTimeout: 0 The slapd debug log is pasted in the URL below. Regards, Martin Bozic

1 0

(ITS#7335) Error in slapo-refint man page
by riggs＠umn.edu 24 Jul '12

24 Jul '12

Full_Name: Benjamin Riggs Version: 2.4.23 OS: http://ftp.scientificlinux.org/linux/scientific/6x/i386/os/Packages/openlda… URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.101.155.71) The slapo-refint man page has only documentation for slapd.conf, not slapd-config. Normally this wouldn't be a problem, but the configuration keywords are not the usual map of simply adding 'olc': refint_attributes is changed to olcRefintAttribute (no 's'!) refint_nothing is changed to olcRefintNothing refint_modifiersname is changed to olcRefintModifiersName

1 0

Re: (ITS#7330) slapd mmr failure due to tls cert name mismatch
by openldap＠stormcloud9.net 24 Jul '12

24 Jul '12

Sent: Tue Jul 24 2012 12:15:27 GMT-0400 (EDT) From: quanah(a)zimbra.com To: openldap-its(a)openldap.org Subject: Re: (ITS#7330) slapd mmr failure due to tls cert name mismatch > Which of the three TLS software packages is your openldap build linked to? > > OpenSSL > MozNSS > GnuTLS > > Thanks, > Quanah > OpenSSL

1 0

Re: (ITS#7330) slapd mmr failure due to tls cert name mismatch
by quanah＠zimbra.com 24 Jul '12

24 Jul '12

--On Friday, July 20, 2012 10:06 PM +0000 openldap(a)stormcloud9.net wrote: > I have also tried tls_reqcert=allow with the same result. And in a > desperate attempt, I also tried setting tls_cacert=/dev/null in the hope > that if it couldn't verify the cert it wouldnt check the hostname against > the cert subject, but this failed as well. Which of the three TLS software packages is your openldap build linked to? OpenSSL MozNSS GnuTLS Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7332) Patch to build using Microsoft Visual Studio
by hyc＠symas.com 23 Jul '12

23 Jul '12

Thanks for the patch, applied to git master. mbooth(a)apache.org wrote: > Full_Name: Mat Booth > Version: 2.4.31 > OS: Windows XP > URL: http://people.apache.org/~mbooth/0001-Changes-required-to-build-with-Micros… > Submission from: (NULL) (77.86.30.139) > > > The provided patch makes three changes that were necessary for me to build > liblber and libldap on Windows using Microsoft Visual Studio. > > > * include/ac/socket.h > The type socklen_t is defined in ws2tcpip.h on the Windows platform, so include > this header when including winsock2.h > > * libraries/libldap/ldap-int.h > The struct timeval is defined in winsock.h or winsock2.h on the Windows platform > so include ac/socket.h when _WIN32 is defined (The comment in winsock2.h > literary says "taken from the BSD file sys/time.h") > > * libraries/libldap/util-int.c > The error code EAI_SYSTEM is not defined at all on the Windows platform, so only > use it if it's defined. > > > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) were > developed by Mat Booth <mbooth(a)apache.org>. I have not assigned rights and/or > interest in this work to any party. > > I, Mat Booth, hereby place the following modifications to OpenLDAP Software (and > only these modifications) into the public domain. Hence, these modifications may > be freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- 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#7332) Patch to build using Microsoft Visual Studio
by mbooth＠apache.org 23 Jul '12

23 Jul '12

Full_Name: Mat Booth Version: 2.4.31 OS: Windows XP URL: http://people.apache.org/~mbooth/0001-Changes-required-to-build-with-Micros… Submission from: (NULL) (77.86.30.139) The provided patch makes three changes that were necessary for me to build liblber and libldap on Windows using Microsoft Visual Studio. * include/ac/socket.h The type socklen_t is defined in ws2tcpip.h on the Windows platform, so include this header when including winsock2.h * libraries/libldap/ldap-int.h The struct timeval is defined in winsock.h or winsock2.h on the Windows platform so include ac/socket.h when _WIN32 is defined (The comment in winsock2.h literary says "taken from the BSD file sys/time.h") * libraries/libldap/util-int.c The error code EAI_SYSTEM is not defined at all on the Windows platform, so only use it if it's defined. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Mat Booth <mbooth(a)apache.org>. I have not assigned rights and/or interest in this work to any party. I, Mat Booth, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7331) [PATCH] MozNSS: ignore untrusted issuer error when verifying server certificate
by jvcelak＠redhat.com 21 Jul '12

21 Jul '12

I forgot to add: The patch deals only with a local certificate validation. It does not have any effect on a remote peer's certificate verification.

1 0

(ITS#7331) [PATCH] MozNSS: ignore untrusted issuer error when verifying server certificate
by jvcelak＠redhat.com 21 Jul '12

21 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120721-moznss-ignore-untrusted-is… Submission from: (NULL) (193.165.79.10) If a self-issued certificate in PEM format is used as a server certificate, the TLS context initialization can fail with SEC_ERROR_UNTRUSTED_ISSUER error. Unfortunately we cannot set trust flags of the server certificate loaded by MozNSS PEM module. This patch allows to ignore this error code. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7330) slapd mmr failure due to tls cert name mismatch
by openldap＠stormcloud9.net 20 Jul '12

20 Jul '12

I've come up with a few more critical details while trying to solve the issue. 1) If the other master is started first, when the local slapd starts, syncrepl connects and works fine. It only fails if the other master is started after the local slapd is running. 2) If I delete the specific olcSyncrepl attribute for one that is failing, and then add it back, syncrepl starts working fine. 3) After deleting and re-adding the olcSyncrepl attribute to make syncrepl work, if I stop and start the other master slapd, syncrepl starts failing again.

1 0

(ITS#7330) slapd mmr failure due to tls cert name mismatch
by openldap＠stormcloud9.net 20 Jul '12

20 Jul '12

Full_Name: Patrick Hemmer Version: 2.4.31 OS: RHEL 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.238.31.70) I have 2 servers (version 2.4.31) in multi-master-replication behind a single IP. Whenever replication tries to start, it fails because the cert name does not match the hostname. ---- TLS: hostname (per5-unity-ldap02.mbox.net) does not match common name in certificate (unity-ldap.mbox.net). 5009c52e slap_client_connect: URI=ldap://per5-unity-ldap02.mbox.net Error, ldap_start_tls failed (-11) 5009c52e do_syncrepl: rid=523 rc -11 retrying (5 retries left) ---- However in the slapd configuration, I have the olcSyncrepl tls_reqcert parameter set to 'never' ---- dn: olcDatabase={3}hdb,cn=config olcSyncrepl: {0}rid=513 provider="ldap://per5-unity-ldap01.mbox.net" network-timeout=2 retry="1 10 10 60 60 +" keepalive="60:3:60" starttls=critical tls_reqcert=never bindmethod=simple timeout=2 binddn="uid=foo,cn=bar" credentials="baz" type=refreshAndPersist searchbase="dc=my,dc=domain" olcSyncrepl: {1}rid=523 provider="ldap://per5-unity-ldap02.mbox.net" network-timeout=2 retry="1 10 10 60 60 +" keepalive="60:3:60" starttls=critical tls_reqcert=never bindmethod=simple timeout=2 binddn="uid=foo,cn=bar" credentials="baz" type=refreshAndPersist searchbase="dc=my,dc=domain" ---- I have also tried tls_reqcert=allow with the same result. And in a desperate attempt, I also tried setting tls_cacert=/dev/null in the hope that if it couldn't verify the cert it wouldnt check the hostname against the cert subject, but this failed as well.

1 0

(ITS#7329) Bottleneck adding a single value to indexed multi-valued attribute
by mhardin＠symas.com 20 Jul '12

20 Jul '12

Full_Name: Matthew Hardin Version: 2.4.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.43.206.100) Opening at Howard Chu's request: When adding a single value to a multi-valued attribute that is indexed, slapd re-adds index entries for every value in the attribute. This is a bottleneck and the code to do this (per Howard) should be reworked.

1 0

(ITS#7328) slapcat fails silently with back-hdb/bdb
by quanah＠OpenLDAP.org 19 Jul '12

19 Jul '12

Full_Name: Quanah Gibson-Mount Version: 2.4 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) As reported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673038, putting slapcat into a loop shows that it periodically fails to correctly dump an active database in full. We have also seen this at customer sites, when nightly backups are run. At the least, slapcat should return an error, so that failure can be caught and a new slapcat run.

1 0

(ITS#7327) [PATCH] smbk5pwd: error if crypto backend unsupported
by jvcelak＠redhat.com 19 Jul '12

19 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120719-smbk5pwd-error-if-crypto-b… Submission from: (NULL) (209.132.186.34) smbk5pwd overlay source code does not expect crypto backend other than OpenSSL or GnuTLS. When OpenLDAP si compiled with Mozilla NSS, Samba password hashes are not computed and the overlay returns uninitialized memory as the hash. This simple patch does not allow the smbk5pwd overlay to be compiled without OpenSSL or GnuTLS. Unfortunately we cannot add support for MozNSS, because MozNSS does not (and will not) implement MD4. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

If I reverse the commit f6b8103b789ae40234b0cb7574c1a9da4e5a1b21 only in add.c then the module runs perfecty. Thanks. 2012/7/19 Alejandro <aescanero(a)gmail.com>: > More information: > Test Module is: > package replicadorTEST; > > use strict; > use warnings; > use POSIX; > > sub new { > my $class = shift; > > my $this = {}; > bless $this, $class; > return $this; > } > > sub bind { > return 0; > } > > sub init { > return 0; > } > > sub search { > return 0; > } > > sub compare { > return 0; > } > > sub modify { > return 0; > } > > sub add { > return 0; > > } > > sub modrdn { > return 0; > } > > sub delete { > return 0; > } > > sub config { > return 0; > } > > 1; > > Try to add this (The problem only appear when try to add a DN): > dn: uid=test,o=XXXX,o=XXXX,c=XX > mailLocalAddress: test(a)test.es > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: inetLocalMailRecipient > objectClass: posixAccount > uid: test > mail: test(a)test.es > uidNumber: 600 > o: ceic > gidNumber: 600 > displayName: TEST > sn: TEST > cn: TEST > homeDirectory: /home/test > > And then I get: > 5007ee79 >>> dnPrettyNormal: <uid=test,o=XXXX,o=XXXX,c=XX> > => ldap_bv2dn(uid=test,o=XXXX,o=XXXX,c=XX,0) > <= ldap_bv2dn(uid=test,o=XXXX,o=XXXX,c=XX)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(uid=test,o=XXXX,o=XXXX,c=XX)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(uid=test,o=XXXX,o=XXXX,c=XX)=0 > 5007ee79 <<< dnPrettyNormal: <uid=test,o=XXXX,o=XXXX,c=XX>, > <uid=test,o=XXXX,o=XXXX,c=XX> > 5007ee79 conn=1000 op=1 ADD dn="uid=test,o=XXXX,o=XXXX,c=XX" > panic: sv_setpvn called with negative strlen. > > Thanks > > 2012/7/19 Alejandro <aescanero(a)gmail.com>: >> My main problem now is: >> How I can check the bad line of code if perl-slapd don't give me any >> usable error in 2.4.31 release? >> >> Thanks >> >> 2012/7/19 Howard Chu <hyc(a)symas.com>: >>> aescanero(a)gmail.com wrote: >>>> The problem was in the perl module with a uninitialized value, in >>>> 2.4.21 give the error Use of uninitialized value in concatenation (.) >>>> or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 >>>> but in 2.4.31 give me a panic. >>> >>> Sounds like a bug in your module then, and not an OpenLDAP software issue. >>> >>> -- >>> -- Howard Chu >>> CTO, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc/ >>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> >> >> >> -- >> Alejandro Escanero Blanco >> Consultor de sistemas basados en fuentes abiertas >> Desarrollador de FusionDirectory (http://www.fusiondirectory.org) >> Blog: http://www.disasterproject.com >> Jabber: blainett(a)jabberes.com > > > > -- > Alejandro Escanero Blanco > Consultor de sistemas basados en fuentes abiertas > Desarrollador de FusionDirectory (http://www.fusiondirectory.org) > Blog: http://www.disasterproject.com > Jabber: blainett(a)jabberes.com -- Alejandro Escanero Blanco Consultor de sistemas basados en fuentes abiertas Desarrollador de FusionDirectory (http://www.fusiondirectory.org) Blog: http://www.disasterproject.com Jabber: blainett(a)jabberes.com

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

More information: Test Module is: package replicadorTEST; use strict; use warnings; use POSIX; sub new { my $class = shift; my $this = {}; bless $this, $class; return $this; } sub bind { return 0; } sub init { return 0; } sub search { return 0; } sub compare { return 0; } sub modify { return 0; } sub add { return 0; } sub modrdn { return 0; } sub delete { return 0; } sub config { return 0; } 1; Try to add this (The problem only appear when try to add a DN): dn: uid=test,o=XXXX,o=XXXX,c=XX mailLocalAddress: test(a)test.es objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetLocalMailRecipient objectClass: posixAccount uid: test mail: test(a)test.es uidNumber: 600 o: ceic gidNumber: 600 displayName: TEST sn: TEST cn: TEST homeDirectory: /home/test And then I get: 5007ee79 >>> dnPrettyNormal: <uid=test,o=XXXX,o=XXXX,c=XX> => ldap_bv2dn(uid=test,o=XXXX,o=XXXX,c=XX,0) <= ldap_bv2dn(uid=test,o=XXXX,o=XXXX,c=XX)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=test,o=XXXX,o=XXXX,c=XX)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=test,o=XXXX,o=XXXX,c=XX)=0 5007ee79 <<< dnPrettyNormal: <uid=test,o=XXXX,o=XXXX,c=XX>, <uid=test,o=XXXX,o=XXXX,c=XX> 5007ee79 conn=1000 op=1 ADD dn="uid=test,o=XXXX,o=XXXX,c=XX" panic: sv_setpvn called with negative strlen. Thanks 2012/7/19 Alejandro <aescanero(a)gmail.com>: > My main problem now is: > How I can check the bad line of code if perl-slapd don't give me any > usable error in 2.4.31 release? > > Thanks > > 2012/7/19 Howard Chu <hyc(a)symas.com>: >> aescanero(a)gmail.com wrote: >>> The problem was in the perl module with a uninitialized value, in >>> 2.4.21 give the error Use of uninitialized value in concatenation (.) >>> or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 >>> but in 2.4.31 give me a panic. >> >> Sounds like a bug in your module then, and not an OpenLDAP software issue. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ > > > > -- > Alejandro Escanero Blanco > Consultor de sistemas basados en fuentes abiertas > Desarrollador de FusionDirectory (http://www.fusiondirectory.org) > Blog: http://www.disasterproject.com > Jabber: blainett(a)jabberes.com -- Alejandro Escanero Blanco Consultor de sistemas basados en fuentes abiertas Desarrollador de FusionDirectory (http://www.fusiondirectory.org) Blog: http://www.disasterproject.com Jabber: blainett(a)jabberes.com

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

My main problem now is: How I can check the bad line of code if perl-slapd don't give me any usable error in 2.4.31 release? Thanks 2012/7/19 Howard Chu <hyc(a)symas.com>: > aescanero(a)gmail.com wrote: >> The problem was in the perl module with a uninitialized value, in >> 2.4.21 give the error Use of uninitialized value in concatenation (.) >> or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 >> but in 2.4.31 give me a panic. > > Sounds like a bug in your module then, and not an OpenLDAP software issue. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Alejandro Escanero Blanco Consultor de sistemas basados en fuentes abiertas Desarrollador de FusionDirectory (http://www.fusiondirectory.org) Blog: http://www.disasterproject.com Jabber: blainett(a)jabberes.com

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by hyc＠symas.com 19 Jul '12

19 Jul '12

aescanero(a)gmail.com wrote: > The problem was in the perl module with a uninitialized value, in > 2.4.21 give the error Use of uninitialized value in concatenation (.) > or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 > but in 2.4.31 give me a panic. Sounds like a bug in your module then, and not an OpenLDAP software issue. -- -- 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#7326) [PATCH] use AI_ADDRCONFIG if defined in the environment
by jvcelak＠redhat.com 19 Jul '12

19 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120719-use-ai-addrconfig-if-defin… Submission from: (NULL) (209.132.186.34) Use AI_ADDRCONFIG flag with getaddrinfo() if the symbol is defined. I think that no configure macro is needed for this. The symbol should be present on the systems which support it. And I believe we can enforce this flag if available. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7325) Panic issue with slapd-perl
by hyc＠symas.com 19 Jul '12

19 Jul '12

aescanero(a)gmail.com wrote: > Full_Name: Alejandro Escanero Blanco > Version: 2.4.31 > OS: RHEL 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.12.24.133) > > > After upgrade Openldap 2.4.21 to 2.4.31 the slapd-perl fail to run add function > in the perl module with this error: > panic: sv_setpvn called with negative strlen, <DATA> line 275 > > Back to 2.4.21 and perl module is running ok. > > A fix is now in git master, please test and report back. Revision 348d43e. -- -- 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#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

The problem was in the perl module with a uninitialized value, in 2.4.21 give the error Use of uninitialized value in concatenation (.) or string at /etc/openldap24/replicador.pm line 109, <DATA> line 275 but in 2.4.31 give me a panic. -- Alejandro Escanero Blanco Consultor de sistemas basados en fuentes abiertas Desarrollador de FusionDirectory (http://www.fusiondirectory.org) Blog: http://www.disasterproject.com Jabber: blainett(a)jabberes.com

1 0

(ITS#7325) Panic issue with slapd-perl
by aescanero＠gmail.com 19 Jul '12

19 Jul '12

Full_Name: Alejandro Escanero Blanco Version: 2.4.31 OS: RHEL 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.12.24.133) After upgrade Openldap 2.4.21 to 2.4.31 the slapd-perl fail to run add function in the perl module with this error: panic: sv_setpvn called with negative strlen, <DATA> line 275 Back to 2.4.21 and perl module is running ok.

1 0

(ITS#7324) [PATCH] autoconf: use pkg-config to detect Mozilla NSS library
by jvcelak＠redhat.com 18 Jul '12

18 Jul '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120718-configure-use-pkg-config-f… Submission from: (NULL) (209.132.186.34) Hello, this patch is just a proposal. It enables pkg-config to detect correct compilation flags for Mozilla NSS crypto backend. I believe this should be adapted also for other dependencies (which support it) instead of hardcoding the flags into the configure script. We might get rid of problems caused by differences between the individual environments (and distributions in case of Linux). Jan The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 18 Jul '12

18 Jul '12

Hi, I had some difficulties to reproduce it, but I have finally succeeded : [Switching to Thread 0x431e4940 (LWP 11061)] 0x000000000054211c in sp_avl_cmp (c1=<value optimized out>, c2=0xbfb5a60) at syncprov.c:378 378 rc = m1->mt_op->o_req_ndn.bv_len - m2->mt_op->o_req_ndn.bv_len; Thank you for the help, David Coutadeur Le 17/07/2012 19:59, Quanah Gibson-Mount a écrit : > --On Tuesday, July 17, 2012 7:47 AM +0000 david.coutadeur(a)linagora.com > wrote: > >> >> Hi everybody, >> >> Does anybody have some news about this ticket ? Is it still valid, or >> maybe is it already solved as a side effect ? >> >> Thanks for any reply, > > Can you reproduce it with current RE24 code from git? > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by Gavin Henry 18 Jul '12

18 Jul '12

Do we want to document this or change behavior?

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by quanah＠zimbra.com 17 Jul '12

17 Jul '12

--On Tuesday, July 17, 2012 7:47 AM +0000 david.coutadeur(a)linagora.com wrote: > > Hi everybody, > > Does anybody have some news about this ticket ? Is it still valid, or > maybe is it already solved as a side effect ? > > Thanks for any reply, Can you reproduce it with current RE24 code from git? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 17 Jul '12

17 Jul '12

Hi everybody, Does anybody have some news about this ticket ? Is it still valid, or maybe is it already solved as a side effect ? Thanks for any reply, D.C. Le 16/03/2012 19:40, David Coutadeur a écrit : > > Hi, > > I finally had the opportunity to get a valgrind analysis of my problem. > You can find it below. Thank you for any help. > > D. > > > > ==19496== 12 bytes in 1 blocks are definitely lost in loss record 16 of 52 > ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) > ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) > ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) > ==19496== by 0x80E0297: do_syncrepl (syncrepl.c:706) > ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) > ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) > ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) > ==19496== > ==19496== 155 (32 direct, 123 indirect) bytes in 1 blocks are definitely > lost in loss record 47 of 52 > ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) > ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) > ==19496== by 0x4057054: ber_bvarray_dup_x (memory.c:756) > ==19496== by 0x80E0212: do_syncrepl (syncrepl.c:699) > ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) > ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) > ==19496== by 0x76146D: clone (in /lib/libc-2.5.so) > ==19496== > ==19496== 270 (228 direct, 42 indirect) bytes in 3 blocks are definitely > lost in loss record 49 of 52 > ==19496== at 0x4005B83: malloc (vg_replace_malloc.c:195) > ==19496== by 0x4056977: ber_memalloc_x (memory.c:228) > ==19496== by 0x8095D39: ch_malloc (ch_malloc.c:54) > ==19496== by 0x8195E91: syncprov_op_search (syncprov.c:2473) > ==19496== by 0x80E3333: overlay_op_walk (backover.c:661) > ==19496== by 0x80E3A09: over_op_func (backover.c:723) > ==19496== by 0x807BE85: fe_op_search (search.c:402) > ==19496== by 0x807C772: do_search (search.c:247) > ==19496== by 0x807988B: connection_operation (connection.c:1150) > ==19496== by 0x807A0FC: connection_read_thread (connection.c:1286) > ==19496== by 0x4016A23: ldap_int_thread_pool_wrapper (tpool.c:688) > ==19496== by 0x821831: start_thread (in /lib/libpthread-2.5.so) > > > > > > Le 20/02/2012 10:32, David Coutadeur a écrit : >> >> Hi, >> >> Concerning the cpu : >> model name : Intel(R) Xeon(R) CPU L5640 @ 2.27GHz >> However, OpenLDAP is used in a virtual machine, with only one dedicated >> core. This is 32 bits version of OpenLDAP, on a 32 bits OS. >> Linux OS : >> Red Hat Enterprise Linux Server release 5.7 (Tikanga) >> kernel : >> 2 2.6.18-274.3.1.el5 >> >> You can get the server configuration below. >> >> Concerning the client, you can find the source code here : >> http://loadtesting.sourceforge.net/index.php?lang=en >> >> >> >> # >> ---------------------------------------------------------------------------- >> # Global section >> # >> ---------------------------------------------------------------------------- >> >> sizelimit 15000 >> >> allow bind_v2 >> password-hash {SSHA} >> threads 8 >> loglevel 256 >> >> serverID 2 >> >> include /opt/openldap/etc/openldap/inc_shemas/slapd-schemas.conf >> >> pidfile /opt/openldap/var/run/slapd.pid >> argsfile /opt/openldap/var/run/slapd.args >> >> # ACLs definition (cutted here) >> >> ####################################################################### >> # SSL definitions >> ####################################################################### >> # Definition of cert files >> # --------------------------------- >> TLSCipherSuite HIGH:MEDIUM:+SSLv2 >> >> TLSCACertificateFile /usr/local/openldap/etc/certs/ca.cert >> TLSCertificateFile /usr/local/openldap/etc/certs/ldap-master-2.cert >> TLSCertificateKeyFile /usr/local/openldap/etc/certs/ldap-master-2.key >> >> TLSVerifyClient never >> >> >> >> ####################################################################### >> # BDB database definitions >> ####################################################################### >> database monitor >> >> ####################################################################### >> # suffix dc=example,dc=com >> # -------------------- >> ####################################################################### >> database bdb >> directory /opt/openldap/var/openldap-data >> # some indexes >> >> # >> ---------------------------------------------------------------------------- >> # root suffix >> # >> ---------------------------------------------------------------------------- >> suffix "dc=example,dc=com" >> checkpoint 512 10 >> >> # >> ---------------------------------------------------------------------------- >> # cache settings >> # >> ---------------------------------------------------------------------------- >> >> cachesize 60000 >> dncachesize 60000 >> idlcachesize 60000 >> cachefree 100 >> >> rootdn "cn=Manager,dc=example,dc=com" >> rootpw secret >> >> # Password policy : hash the clear passwords >> overlay ppolicy >> ppolicy_hash_cleartext >> >> >> # >> ---------------------------------------------------------------------------- >> # REPLICATION definitions >> # >> ---------------------------------------------------------------------------- >> ####################################################################### >> >> # I am a master (provider) >> # ------------------------------------------ >> overlay syncprov >> syncprov-checkpoint 100 10 >> syncprov-sessionlog 100 >> >> # syncrepl directive (consummer infos) >> # ------------------------------------------ >> syncrepl rid=001 >> provider=ldap://ldap-master-1.example.com >> bindmethod=simple >> binddn="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" >> credentials=secret >> searchbase="dc=example,dc=com" >> schemachecking=on >> type=refreshAndPersist >> retry="60 +" >> >> mirrormode on >> >> >> # >> ---------------------------------------------------------------------------- >> # limits >> # >> ---------------------------------------------------------------------------- >> >> limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> >> >> ####################################################################### >> # suffix o=edition >> # ---------------- >> ####################################################################### >> database bdb >> >> directory /opt/openldap/var/openldap-data-edition >> # some indexes >> >> >> # >> ---------------------------------------------------------------------------- >> # root suffix >> # >> ---------------------------------------------------------------------------- >> suffix "o=edition" >> checkpoint 512 10 >> >> # >> ---------------------------------------------------------------------------- >> # cache settings >> # >> ---------------------------------------------------------------------------- >> >> cachesize 50000 >> dncachesize 50000 >> idlcachesize 50000 >> cachefree 100 >> >> >> >> # >> ---------------------------------------------------------------------------- >> # rootdn >> # >> ---------------------------------------------------------------------------- >> # Cleartext passwords, especially for the rootdn, should >> # be avoid. See slappasswd(8) and slapd.conf(5) for details. >> # Use of strong authentication encouraged. >> rootdn "cn=Manager,o=edition" >> rootpw secret >> >> # Password policy : hash the clear passwords >> overlay ppolicy >> ppolicy_hash_cleartext >> >> >> ####################################################################### >> # REPLICATION definitions >> ####################################################################### >> >> # I am a master (provider) >> # ------------------------------------------ >> overlay syncprov >> syncprov-checkpoint 100 10 >> syncprov-sessionlog 100 >> >> # syncrepl directive (consummer infos) >> # ------------------------------------------ >> syncrepl rid=002 >> provider=ldap://vspar-ldap-master-1.example.com >> bindmethod=simple >> binddn="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" >> credentials=secret >> searchbase="o=edition" >> schemachecking=on >> type=refreshAndPersist >> retry="60 +" >> >> mirrormode on >> >> # >> ---------------------------------------------------------------------------- >> # Limits for current BDB >> # >> ---------------------------------------------------------------------------- >> >> limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special >> Users,dc=example,dc=com" size=unlimited time=unlimited >> >> >> >> >> >> Le 17/02/2012 19:00, Howard Chu a écrit : >>> dcoutadeur(a)linagora.com wrote: >>>> Full_Name: dcoutadeur >>>> Version: 2.4.28 >>>> OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (109.197.176.10) >>>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> I had a segfault in the last git version of OpenLDAP, after 10 to 15 >>>> tests, each >>>> interrupted by Ctrl+C. (see what's a test below) >>>> The segfault is also reproduced in version 2.4.28. >>>> >>>> I think I won't be able to reproduce the bug with Valgrind. >>> >>> If you expect us to try to reproduce the bug, you'll have to provide >>> more information. Since this crash is in syncprov there's obviously at >>> least two servers involved; what are their configurations? What hardware >>> are they running on (in particular, how many CPU cores per server)? >>> Since you're using a custom client, can you provide the client source code? >>>> >>>> Thank you in advance for any help. >>>> >>>> D. >>>> >>>> >>>> Note : A test is 100 times 100 threads, each doing a bind, an add, a >>>> modify, a >>>> delete, and a logout. >>>> >>>> >>>> >>>> >>>> >>>> (gdb) bt full >>>> #0 sp_avl_cmp (c1=0x8b4004c8, c2=0xa37cf28) at syncprov.c:366 >>>> rc =<value optimized out> >>>> #1 0x081afe3e in avl_delete (root=0xa255648, data=0x8b4004c8, >>>> fcmp=0x81948a0<sp_avl_cmp>) at avl.c:197 >>>> p =<value optimized out> >>>> q =<value optimized out> >>>> r =<value optimized out> >>>> top =<value optimized out> >>>> side =<value optimized out> >>>> side_bf =<value optimized out> >>>> shorter =<value optimized out> >>>> nside =<value optimized out> >>>> pptr = {0x89908, 0x0, 0x0, 0x0, 0xe8043c, 0x0, 0xfdc, >>>> 0x8d994858, 0xe7b95c, 0xfdc, 0xa372570, 0x0, 0xa288350, >>>> 0xe8043c, 0xa372570, 0x8d994878, 0xe7c324, 0xfdc, 0xa372570, >>>> 0x0, 0xe7af2c, 0x8cb9136e, 0x81b3634, 0x0, 0xe8043c, >>>> 0xe, 0xa3d3a40, 0x8d9948b8, 0xe7d081, 0xa3e3618, 0x8cb91358, >>>> 0x823c27} >>>> pdir = >>>> "\000\000\000\000lI\231\215\064\066\033\bn>\000\000\244\345t\000\310\004@\213\b\346\067\n\310H\231\215" >>>> >>>> depth = 0 >>>> #2 0x08199f7f in syncprov_op_cleanup (op=0xa37e608, rs=0x8d995108) at >>>> syncprov.c:1401 >>>> cb = 0x8cb91258 >>>> opc = 0x8cb91268 >>>> si = 0xa255610 >>>> sm = 0xa255688 >>>> snext =<value optimized out> >>>> mt = 0x8b4004c8 >>>> #3 0x08089654 in slap_cleanup_play (op=0xa37e608, rs=0x8d995108) at >>>> result.c:541 >>>> sc_next = 0x8d994dec >>>> sc = 0x8cb91258 >>>> scp = 0x8d994928 >>>> #4 0x0808a150 in send_ldap_response (op=0xa37e608, rs=0x8d995108) at >>>> result.c:733 >>>> berbuf = { >>>> buffer = "\000\000\001\000\000\001\000\000\377\377\377\377", >>>> '\000'<repeats 12 times>, >>>> "f\023\271\214\064#\271\214\000\000\000\000f\023\271\214p%7\n\000\000\000\000\314I\231\215\001\000\000\000\000\000\000\000\314mK\236x\271\347\000\001\000\000\000`+@\213D`K\236\230\063\066\n\250<6\n\000\000\000\000\000\000\000\000\005\000\000\000P7@\213`\343\070\n\000\000\000\000\n\000\000\000(\234\200\330\000\000\000\000\000\000\000\000@4\"\000\000\000\000\000(\234\200\330\210J\231\215\270\214 >>>> >>>> \000\230\063\066\n`+@\213\314mK\236\r\000\000\000\001\000\000\000\021\217;O(\234\200\330\000\000\000\000`&%\n`&%\n8J\231\215b\f\"\000\224mK\236\230\063\066\n(\234\200أ\347\022\b\a", >>>> >>>> '\000'<repeats 31 times>, "D'%\n\224mK\236\000\000\000", >>>> ialign = 65536, lalign = 65536, falign = 9.18354962e-41, >>>> dalign = 5.4323095486619588e-312, >>>> palign = 0x10000<Address 0x10000 out of bounds>} >>>> ber =<value optimized out> >>>> rc = 32768 >>>> bytes = 14 >>>> __PRETTY_FUNCTION__ = "send_ldap_response" >>>> #5 0x0808af1f in slap_send_ldap_result (op=0xa37e608, rs=0x8d995108) at >>>> result.c:860 >>>> tmp = 0x0 >>>> otext = 0x0 >>>> oref = 0x0 >>>> __PRETTY_FUNCTION__ = "slap_send_ldap_result" >>>> #6 0x0812bde5 in bdb_add (op=0xa37e608, rs=0x8d995108) at add.c:511 >>>> pdn = {bv_len = 23, bv_val = 0x8b40372f >>>> "ou=people,dc=afp,dc=com"} >>>> p = 0x8fc4c0fc >>>> oe = 0x8fc4c804 >>>> ei = 0xa37d1c8 >>>> textbuf = "\000\000\000\000\320O\"\n", '\000'<repeats 48 >>>> times>, "\001", '\000'<repeats 198 times> >>>> children = 0xa223b20 >>>> entry = 0xa223980 >>>> ltid = 0x0 >>>> lt2 = 0x8b402bf0 >>>> eid = 57976 >>>> opinfo = {boi_oe = {oe_next = {sle_next = 0x8d99509c}, oe_key = >>>> 0x0}, boi_txn = 0x8b402b60, boi_locks = 0x0, >>>> boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} >>>> lock = {off = 133260, ndx = 772, gen = 2004, mode = >>>> DB_LOCK_READ} >>>> num_retries = 0 >>>> success = 0 >>>> postread_ctrl = 0x0 >>>> ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0} >>>> num_ctrls = 0 >>>> #7 0x080e33a1 in overlay_op_walk (op=0xa37e608, rs=0x8d995108, >>>> which=op_add, oi=0xa254ff0, on=0xa255508) at backover.c:671 >>>> rc = 32768 >>>> #8 0x080e3a0a in over_op_func (op=0xa37e608, rs=0x8d995108, >>>> which=op_add) at backover.c:723 >>>> oi = 0xa254ff0 >>>> on = 0xa255508 >>>> be = 0xa252560 >>>> db = {bd_info = 0x821d41c, bd_self = 0xa252560, >>>> be_ctrls = >>>> "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001\000\000\000\000\001\000\001\000\000\000\000\000\000\000\000\000\001", >>>> >>>> be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = >>>> {sss_ssf = 0, >>>> sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf >>>> = 0, sss_update_transport = 0, sss_update_tls = 0, >>>> sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = >>>> 0xa288350, be_nsuffix = 0xa288368, be_schemadn = { >>>> bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, >>>> bv_val = 0x0}, be_rootdn = {bv_len = 24, >>>> bv_val = 0xa287648 "cn=Manager,dc=afp,dc=com"}, be_rootndn = >>>> {bv_len = 24, >>>> bv_val = 0xa2876d0 "cn=manager,dc=afp,dc=com"}, be_rootpw = >>>> {bv_len = 38, >>>> bv_val = 0xa2876f0 >>>> "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, >>>> be_def_limit = { >>>> lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, >>>> lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, >>>> lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = >>>> 0xa255748, be_acl = 0x0, be_dfltaccess = ACL_READ, >>>> be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = >>>> 0x0}, be_update_refs = 0x0, >>>> be_pending_csn_list = 0xa363388, be_pcl_mutex = {__data = >>>> {__lock = 0, __count = 0, __owner = 0, __kind = 0, >>>> __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, >>>> __size = '\000'<repeats 23 times>, __align = 0}, >>>> be_syncinfo = 0xa28aec8, be_pb = 0x0, be_cf_ocs = 0x821f840, >>>> be_private = 0xa252660, be_next = { >>>> stqe_next = 0xa288538}} >>>> cb = {sc_next = 0x0, sc_response = 0x80e30e0 >>>> <over_back_response>, sc_cleanup = 0, sc_private = 0xa254ff0} >>>> sc =<value optimized out> >>>> rc =<value optimized out> >>>> __PRETTY_FUNCTION__ = "over_op_func" >>>> #9 0x08081129 in fe_op_add (op=0xa37e608, rs=0x8d995108) at add.c:334 >>>> repl_user = 0 >>>> rc =<value optimized out> >>>> bd = 0x82234c0 >>>> textbuf = >>>> "\000\000\000\000\000\000\000\000\060[\231\215\000\000\000\000\035\000\000\000\020\070@\213\001\000\000\000xN\231\215\270\026@\213(I\"\n\002\000\000\000\250N\231\215\255\214\v\b\270\026@\213\224N\231\215\001\000\000\000\000\000\000\000x9@\213\000\000\000\000\n\000\000\000\001\000\000\000\340\067@\213\n\000\000\000\060\070@\213\320\026@\213(I\"\n\270\026@\213\370N\231\215oc\t\b\002\000\000\000X( >>>> >>>> \n\370N\231\215\321_\t\bh\234!\n\240\066@\213'<\202\000\000\000\000\000\f\000\000\000W.@\213n>\000\000\244\345t\000\320O\"\n\320O\"\n\370N\231\215\035\205q\000 >>>> >>>> .\"\b\314h\032\216\030O\231\215\245\063\b\b >>>> .\"\b\240\066@\213\000\000\000\000\270\026@\213\244i\032\216\000\000\000\000HO\231\215\267\r\b\b\320O\"\n\320O\"\n\001\000\000\000HO\231\215\020\000\000\000\340h\032\216\377\377\377\377" >>>> >>>> __PRETTY_FUNCTION__ = "fe_op_add" >>>> #10 0x08081a13 in do_add (op=0xa37e608, rs=0x8d995108) at add.c:194 >>>> ber =<value optimized out> >>>> last = 0x8b402e71 "" >>>> dn = {bv_len = 38, bv_val = 0x8b402d98 >>>> "uid=dcoutadeur,ou=People,dc=afp,dc=com"} >>>> len = 28 >>>> tag =<value optimized out> >>>> modlist = 0x8b4015f0 >>>> modtail = 0x8b403694 >>>> tmp = {sml_mod = {sm_desc = 0x80ce5ca, sm_values = 0x8b4036a0, >>>> sm_nvalues = 0x0, sm_numvals = 2375635128, >>>> sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = >>>> 0x8b402e57 "userPassword"}}, sml_next = 0x823c27} >>>> textbuf = >>>> "\025\000\000\000\310\031@\213\b\026@\213\006\340(\000\220[\231\215\000\000\000\000\000\000\000\000\020\000@\213\025\000\000\000\310\031@\213\310+@\213\005\070/\000\200O@\213T\245(\000\000\000\000\000\020\000@\213\364\237\067\000\220[\231\215\000\000\000\000\233\071@\213@:=\n\370O\231\215T\213\202\000b\213\202\000;\334\347\000\"\000\000\000\233\071@\213\b\000\000\000\201\354(\000\fP\231\215<\004\350\000\270P\231\215\312\315\347\000\370\326\070\n\233\071@\213\b\000\000\000\001\200\255\373\b\347\067\n@\000\000\000\243P\231\215@\000@\213\026\347\067\n@\000@\213\b\347\067\n@\261\067\000,\000\000\000\020\000@\213", >>>> >>>> '\000'<repeats 20 times>, >>>> "5\000\000\000@\000@\213\000\000\000\000\340\021@\213\000\000\000\000\000\000\000\000\260+@\213\000\000\000\000\001\000\000\000\004\000\020\000\350Q\231\215\310P\231\215" >>>> >>>> rc =<value optimized out> >>>> freevals =<value optimized out> >>>> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x8081330}, >>>> oe_db = 0x0} >>>> #11 0x0807988c in connection_operation (ctx=0x8d9951e8, arg_v=0xa37e608) >>>> at connection.c:1150 >>>> rc =<value optimized out> >>>> cancel =<value optimized out> >>>> rs = {sr_type = REP_RESULT, sr_tag = 105, sr_msgid = 2, sr_err = >>>> 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, >>>> sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, >>>> r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, >>>> r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = >>>> 0x0}, sru_extended = {r_rspoid = 0x0, >>>> r_rspdata = 0x0}}, sr_flags = 0} >>>> tag = 104 >>>> opidx = SLAP_OP_ADD >>>> conn = 0xb7f3bc10 >>>> memctx = 0xa372570 >>>> memctx_null = 0x0 >>>> __PRETTY_FUNCTION__ = "connection_operation" >>>> #12 0x0807a0fd in connection_read_thread (ctx=0x8d9951e8, argv=0x22) at >>>> connection.c:1286 >>>> s =<value optimized out> >>>> #13 0x00717a24 in ldap_int_thread_pool_wrapper (xpool=0xa2265c8) at >>>> tpool.c:688 >>>> task = 0xa382e10 >>>> work_list =<value optimized out> >>>> ctx = {ltu_id = 2375637904, ltu_key = {{ltk_key = 0x80ce400, >>>> ltk_data = 0xa372570, >>>> ltk_free = 0x80ce430<slap_sl_mem_destroy>}, {ltk_key = >>>> 0xa363398, ltk_data = 0xa371a88, >>>> ltk_free = 0x812e4c0<bdb_reader_free>}, {ltk_key = >>>> 0x8078320, ltk_data = 0xa37de68, >>>> ltk_free = 0x80783f0<conn_counter_destroy>}, {ltk_key = >>>> 0x808dde0, ltk_data = 0x0, >>>> ltk_free = 0x808dbf0<slap_op_q_destroy>}, {ltk_key = 0x0, >>>> ltk_data = 0x0, ltk_free = 0}<repeats 28 times>}} >>>> kctx =<value optimized out> >>>> keyslot = 241 >>>> hash = 5278961 >>>> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" >>>> #14 0x00821832 in start_thread () from /lib/libpthread.so.0 >>>> No symbol table info available. >>>> #15 0x002f746e in clone () from /lib/libc.so.6 >>>> No symbol table info available. >>>> >>>> >>>> >>>> >>>> >>> >>> > -- David Coutadeur - intégrateur LinID Groupe LINAGORA - BU LGS +33 1 46 96 63 63 / poste 601 80 rue Roque de Fillol 92800 PUTEAUX "/La présente transmission contient des informations confidentielles appartenant à Linagora, exclusivement destinées au(x) destinataire(s) identifié(s) ci-dessus. Si vous n'en faites pas partie, toute reproduction, distribution ou divulgation de tout ou partie des informations de cette transmission, ou toute action effectuée sur la base de celles-ci vous sont formellement interdites. Si vous avez reçu cette transmission par erreur, nous vous remercions de nous en avertir et de la détruire de votre système d'information. The present transmission contains privileged and confidential information belonging to Linagora, exclusively intended for the recipient(s) thereabove identified. If you are not one of these aforementioned recipients, any reproduction, distribution, disclosure of said information in whole or in part, as well as any action undertaken on the basis of said information are strictly prohibited. If you received the present transmission by mistake, please inform us and destroy it from your messenging and information systems./"

1 0

Re: (ITS#7299) Memory leaks when using ldapmodify to add members to groupOfNames objectclass
by jsynacek＠redhat.com 12 Jul '12

12 Jul '12

On 06/18/2012 01:55 PM, hyc(a)symas.com wrote: > Jan Synacek wrote: >> On 06/15/2012 03:16 PM, hyc(a)symas.com wrote: >>> jsynacek(a)redhat.com wrote: >>>> Full_Name: Jan Synacek >>>> Version: git (c73ec15) >>>> OS: linux-fedora17 >>>> URL: http://jsynacek.fedorapeople.org/openldap/leak/openldap-mmr-leak.tar.gz >>>> Submission from: (NULL) (209.132.186.34) >>>> >>>> >>>> I'm using a 2-node mmr setup on my local machine - configuration files and >>>> 'uploader' scripts are provided in the archive. >>>> >>>> 1) I have the two nodes running. >>>> 2) Execute run.sh (only a wrapper for ldapusradm.sh) and start monitoring >>>> slapd's memory usage. >>>> 3) After some time (at about 2k users on my system), slapd consumes a large >>>> amount of memory which is still growing >>>> >>>> Note that not using ldapmodify to add members to 'cn=users,dc=yes,dc=my', but >>>> using it e.g. for modifying each user's email, does NOT result in any memory >>>> leakage. >>>> >>>> I have also created a massif output using valgrind's massif tool: >>>> http://jsynacek.fedorapeople.org/openldap/leak/massif.out.17906 >>>> >>>> I found a very similar bug (#7292), but I'm not sure if it's related. >>> >>> Running RE24 with valgrind --leak-check=full I see no leak when running your >>> test. That should be the same as git c73ec15. No idea what leak you're seeing. >>> >> >> The memory consumption still grows and slapd eventually gets killed by oom-killer. > > Perhaps you're seeing fragmentation in the glibc malloc library. Please test > RE24, and try with some other malloc (e.g. tcmalloc). I've run your entire > test with both valgrind and with tcmalloc's heap checker and neither one shows > any leak. > I've done more tests and have some additional observations to add: * tcmalloc doesn't make any difference * if syncing finishes, memory usage drops considerably * putting sleep between ldapadd and ldapmodify in the script seems to stop the memory consumption * also, generating one big ldif, that is used modify all the users in groupOfNames just once (calling ldapmodify only once that is, not calling it once for every user), seems to help as well; the ldif is formatted like so: dn: cn=users,dc=yes,dc=my changetype:modify add: member member: uid=test-1(a)yes1.my,dc=yes,dc=my - add: member member: uid=test-2(a)yes1.my,dc=yes,dc=my - ... I'm also including my configure setup: export CFLAGS="$(rpm --eval %{optflags}) -O2 -fPIC -D_REENTRANT -DHAVE_TLS -DHAVE_MOZNSS" export LIBS="-lpthread -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4" CFLAGS="${CFLAGS:--g -pipe -Wall }"; export CFLAGS; CXXFLAGS="${CXXFLAGS:--g -pipe -Wall }"; export CXXFLAGS; FFLAGS="${FFLAGS:--g -pipe -Wall }"; export FFLAGS; ./configure \ --with-threads=posix --disable-static --with-tls=no \ --with-pic --with-cyrus-sasl \ --enable-bdb \ --enable-overlays --enable-slapd --enable-spasswd --enable-modules --enable-slapi \ --enable-accesslog \ --enable-wrappers -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

(ITS#7323) back-mdb online indexer memory leak
by hyc＠OpenLDAP.org 12 Jul '12

12 Jul '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.226.5.35) Submitted by: hyc The online indexer doesn't free entries that it has reindexed. A patch is coming.

1 0

ITS#6262 regression
by hyc＠symas.com 10 Jul '12

10 Jul '12

While running valgrind --tool=helgrind on test008 I saw some data races that were quite unexpected, in ldap_pvt_gettime(). These functions are supposed to detect duplicate timestamps being returned, as noted in git rev 6cbf65642a9d094feddf820b206c1a3af70d5fd9 . This detection relies on static variables, and as such their invocations must be mutex-protected, as noted in the function comments (added immediately after, in ee2001ea4b26b0957040ca0753a94f26f78e6147). Unfortunately in f3cdcadf89474e7267d9f8f17d2bac46551b2131 the necessary mutex was removed. This means on multi-processor machines it's possible for us to generate non-unique CSNs. -- -- 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#7322) Problem in LDAP Server
by quanah＠zimbra.com 05 Jul '12

05 Jul '12

--On Friday, July 06, 2012 5:20 AM +0000 kashif.hameed(a)vopium.com wrote: > Full_Name: Kashif Hameed > Version: openldap-2.3.43 > OS: Centos 32 Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.215.176.22) > > > Dear All > please help me its my first job and its my final assignment my job is > totally on this assignment. The ITS system is for reporting bugs. You have not reported a bug, this ITS will be closed. If you want the help you are desperately seeking, I would advise you to use the openldap-technical(a)openldap.org mail list, as advised on the openldap.org website for use when seeking help. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7322) Problem in LDAP Server
by kashif.hameed＠vopium.com 05 Jul '12

05 Jul '12

Full_Name: Kashif Hameed Version: openldap-2.3.43 OS: Centos 32 Bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.215.176.22) Dear All please help me its my first job and its my final assignment my job is totally on this assignment. We have multiple servers of linux, Centos and Ubuntu, Debian my boss want to implement openldap in this situation that user will manage from central location. so i have started work on this and successfull to implement 1 case that is if we will create a simple user its authanticate but when we want to give sudo rights then it will return error here is the eroor please help me how to resolve this issue [root@ldapprod ~]# service ldap restart Stopping slapd: [ OK ] Checking configuration files for slapd: [FAILED] /etc/openldap/schema/sudo.schema: line 1: AttributeType SYNTAX or SUPerior required: "sudoUser" slaptest: bad configuration file! Here is the file for your reference please look into this where syntax is wrong attributetype ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' ) DESC 'User(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC 'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC 'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoOption $ description ) X-ORIGIN 'SUDO' ) Thanks

1 0

(ITS#7321) Subtree replication: when removing object outside of subtree, contextCSN is not updating!
by kostjnspb＠yandex.ru 05 Jul '12

05 Jul '12

Full_Name: Konstantin Menshikov Version: 2.4.31 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/kmenshikov-120705.ext Submission from: (NULL) (212.116.101.94) I have replication setup, when i replicate not entire tree, but only part of it. Configuration provider and consumer attached. I use openldap-server-2.4.31 and db47-4.7.25.4 While adding object outside of the replicated subtree: e.g. ou=TestBranch1,dc=example,dc=com contextCSN of dn dc=example,dc=com on consumer server updated, ok. But while removing object, contextCSN not updated! Is it expected behavior or not? At first I added object *ou=hosts,ou=TestBranch2,dc=example,dc=com*.1 After I removed object. Provider log: Jun 22 06:37:53 ro1 slapd[62268]: conn=1002 op=52 SRCH base="ou=hosts,ou=TestBranch2,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" Jun 22 06:37:53 ro1 slapd[62268]: conn=1002 op=52 SRCH attr=hasSubordinates objectClass Jun 22 06:37:53 ro1 slapd[62268]: conn=1002 op=52 SEARCH RESULT tag=101 err=32 nentries=0 text= Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=53 ADD dn="ou=hosts,ou=TestBranch2,dc=example,dc=com" Jun 22 06:37:54 ro1 slapd[62268]: slap_queue_csn: queing 0x7ffffe3fb100 20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=53 RESULT tag=105 err=0 text= Jun 22 06:37:54 ro1 slapd[62268]: slap_graduate_commit_csn: removing 0x80191bfd0 20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=54 SRCH base="ou=hosts,ou=TestBranch2,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=54 SRCH attr=hasSubordinates objectClass Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=54 SEARCH RESULT tag=101 err=0 nentries=1 text= Jun 22 06:38:01 ro1 slapd[62268]: conn=1002 op=55 DEL dn="ou=hosts,ou=TestBranch2,dc=example,dc=com" Jun 22 06:38:01 ro1 slapd[62268]: slap_queue_csn: queing 0x7ffffebfc590 20120622063801.799710Z#000000#000#000000 Jun 22 06:38:01 ro1 slapd[62268]: conn=1002 op=55 RESULT tag=107 err=0 text= Jun 22 06:38:01 ro1 slapd[62268]: slap_graduate_commit_csn: removing 0x802738970 20120622063801.799710Z#000000#000#000000 Jun 22 06:38:02 ro1 slapd[62268]: conn=1002 op=56 SRCH base="ou=TestBranch2,dc=example,dc=com" scope=1 deref=3 filter="(objectClass=*)" Jun 22 06:38:02 ro1 slapd[62268]: conn=1002 op=56 SRCH attr=hasSubordinates objectClass Jun 22 06:38:02 ro1 slapd[62268]: conn=1002 op=56 SEARCH RESULT tag=101 err=0 nentries=2 text= Consumer log: Jun 22 06:37:54 ro2 slapd[62298]: do_syncrep2: rid=111 LDAP_RES_INTERMEDIATE - NEW_COOKIE Jun 22 06:37:54 ro2 slapd[62298]: do_syncrep2: rid=111 NEW_COOKIE: rid=111,csn=20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro2 slapd[62298]: slap_queue_csn: queing 0x8019eca90 20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro2 slapd[62298]: slap_graduate_commit_csn: removing 0x8019ec2b0 20120622063754.599740Z#000000#000#000000

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by Gavin Henry 04 Jul '12

04 Jul '12

Do we want to document this or change behavior?

1 0

Re: ITS#7317
by hyc＠symas.com 03 Jul '12

03 Jul '12

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Hmm, another 100 iterations without a problem. Not sure whether it's related >>> to back-mdb or whether this may happen occasionally with other backends too. >>> Trying more... >> >> Looks like a simple timing dependency in the test script. slapcat of the DB in >> your testrun directory shows that the correct value is present. The refint >> overlay does its work in a separate task, so there's no guarantee it will be >> done by the time the original modrdn request finishes. > > Ok, noted. > >> We could add a SLEEP in the script here but it seems to be such a rare >> occurrence I'm inclined to ignore it. > > Hmm, I'd argue that a SLEEP would be helpful to avoid further questions about > it. A OpenLDAP packager might run "make test" routinely and this issue aborts it. I've replaced the hardcoded "sleep 1" in the script with "sleep $SLEEP0" so it can be overridden along with the other SLEEP1/SLEEP2 values. Packagers running the tests should either ensure they're on an idle enough machine, or set larger values in their environment... -- -- 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#7320) ldap failed to bind
by rajeshece447＠gmail.com 28 Jun '12

28 Jun '12

Full_Name: raj kas Version: e16 OS: oracle linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.135.212.242) Today while working on APIGEE installation i ran into an ldap issue, clearly explained below. first installed apigee successfully and then i have to configure that apigee with openldap. For that i downloaded some openldap-clients and server rpms. After that changed password using SHA updated the slapd.conf file then restarted the ldap. Then i try to run a curl command {curl -v -X POST 'http://localhost:8080/v1/securityprofile' -H'content-type: application/xml' -d '<SecurityProfile><UserAccessControl enabled="true"/></SecurityProfile>'} to enable the user access, the response i got is 200ok but try to look in to apigee logs found an error as below 17:18:25.778 qtp60863806-35 INFO SERVICES.SECURITY - LDAPClient.createOrganizationalUnit() : LDAPClient.createOrganizationalUnit : Look up failed. Binding ou=users,dc=apigee,dc=com 17:18:25.783 qtp60863806-35 INFO SERVICES.SECURITY - LDAPClient.createOrganizationalUnit() : LDAPClient.createOrganizationalUnit : Look up failed. Binding ou=userroles,dc=apigee,dc=com 17:18:25.808 qtp60863806-35 INFO SERVICES.SECURITY - LDAPClient.initRoles() : LDAPClient.init() : Roles are not defined in ldap store. Initializing roles under dir ou=roles,dc=apigee,dc=com 17:47:11.259 qtp60863806-38 WARN SERVICES.SECURITY - UserAccessController.authorize() : UserAccessController.authorize : User name is not populated in the subject. Skipping authorization. 17:47:11.322 qtp60863806-39 WARN SERVICES.SECURITY - UserAccessController.authorize() : UserAccessController.authorize : User name is not populated in the subject. Skipping authorization. 17:47:11.324 qtp60863806-39 INFO SERVICES.SECURITY - LDAPClient.createOrganizat ionalUnit() : LDAPClient.createOrganizationalUnit : Look up failed. Binding ou=g lobal,ou=userroles,dc=apigee,dc=com

1 0

(ITS#7318) Error in slapd-config man page
by riggs＠umn.edu 26 Jun '12

26 Jun '12

Full_Name: Benjamin Riggs Version: 2.4.23 OS: http://ftp.scientificlinux.org/linux/scientific/6x/i386/os/Packages/openlda… URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.101.155.71) The example LDIF suitable for slapadd contains the line: include: /etc/openldap/schema/core.ldif This results in an error running slapadd. It should read (and does on the website): include: file:///etc/openldap/schema/core.ldif

1 0

Re: ITS#7317
by michael＠stroeder.com 26 Jun '12

26 Jun '12

This is a cryptographically signed message in MIME format. --------------ms040404000804090204020205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > michael(a)stroeder.com wrote: >> Hmm, another 100 iterations without a problem. Not sure whether it's r= elated >> to back-mdb or whether this may happen occasionally with other backend= s too. >> Trying more... >=20 > Looks like a simple timing dependency in the test script. slapcat of th= e DB in > your testrun directory shows that the correct value is present. The ref= int > overlay does its work in a separate task, so there's no guarantee it wi= ll be > done by the time the original modrdn request finishes. Ok, noted. > We could add a SLEEP in the script here but it seems to be such a rare > occurrence I'm inclined to ignore it. Hmm, I'd argue that a SLEEP would be helpful to avoid further questions a= bout it. A OpenLDAP packager might run "make test" routinely and this issue ab= orts it. Ciao, Michael. --------------ms040404000804090204020205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjI2MTYwMzUzWjAjBgkq hkiG9w0BCQQxFgQUb8fucJFt8qQlWtfGqjItIP13+dcwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAdsYRVP5QgW6lXnu7ux2qIN8RhWjPwiJ0c5CmFK/aNhPisi56lBwsi3eA46jisXo607ch gGR3qNA05xxNx03VfCsIk2Fbwfh5sA0dsf4Gf9J7vToUgBkmCYAeDbS6ngIVtinTUUpK3yjm 9xfo0JBvjy+g2BomwwFSkbbbw0jT/C/Ugfur9HiOArNpdL6mdmZ4jLQUrlhF1MPB6RMgexSB tuMnZj0lmwDizeyZzWu6ntkW1eiz7sK3xjTWKJpyVwa0ff4WBPom+/6gX1QwT0JohZC5NDFB cBl1mw/QCgLHG8EICHytxHoRnO4R14w9vrVJiSGIuZGiNbCJ3Q3SuDEFRAAAAAAAAA== --------------ms040404000804090204020205--

1 0

Re: (ITS#7308) [PATCH] contrib/slapd-modules: Add missing missing Makefiles
by hyc＠symas.com 26 Jun '12

26 Jun '12

fumiyas(a)osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master, 2.4.31 > OS: > URL: https://gist.github.com/2931574 > Submission from: (NULL) (114.48.132.80) > > > In contrib/slapd-modules, some modules have no Makefile to build and install > itself. > I've created a patch to add Makefile and update README for that. Thanks for the patches, applied to master. This also seems to obsolete ITS#6883. -- -- 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#7317
by hyc＠symas.com 26 Jun '12

26 Jun '12

michael(a)stroeder.com wrote: > Hmm, another 100 iterations without a problem. Not sure whether it's related > to back-mdb or whether this may happen occasionally with other backends too. > Trying more... Looks like a simple timing dependency in the test script. slapcat of the DB in your testrun directory shows that the correct value is present. The refint overlay does its work in a separate task, so there's no guarantee it will be done by the time the original modrdn request finishes. We could add a SLEEP in the script here but it seems to be such a rare occurrence I'm inclined to ignore it. -- -- 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#7317
by michael＠stroeder.com 25 Jun '12

25 Jun '12

Hmm, another 100 iterations without a problem. Not sure whether it's related to back-mdb or whether this may happen occasionally with other backends too. Trying more...

1 0

ITS#7317
by michael＠stroeder.com 25 Jun '12

25 Jun '12

This is a cryptographically signed message in MIME format. --------------ms070207060701040109000201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable See testrun/ here: http://www.stroeder.com/temp/openldap-its7317-testrun.tar.bz2 --------------ms070207060701040109000201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNjI1MjAwMDI3WjAjBgkq hkiG9w0BCQQxFgQUtiyKRxKgXS5VtfqjZUVjAHIMNoowbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAalN+30Ry/SMDuQg90TiynKL+uJZW/M83Nzy0FgsmpXuv/I7RaL6RELxMHA5sAbtdcIGu PDOSIemgQisdHNgkbh4PEsCR86wT++zd+UVYQHhsTxCsf9+BTSOoU/OxovwvIag4ww4shC8v 4OPAobZOWflcYgP//7OhEkDc8rwKx4nuLTfcEeqOm+mvZWjIl0Il/KltUme3xJ7xWMTmGFs+ D7P1OUUGs/X2sAWC+2dCHWcfnhINvGG+28TeuKNXJQdPusrFsIGynYMrbpx2eU0UMvhWoGyh Lk76onqKzeBBW0hs1cWU2soOnRzVC43Eyk8itxlswEoSk4EyNPx4vTmMdAAAAAAAAA== --------------ms070207060701040109000201--

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by hyc＠symas.com 25 Jun '12

25 Jun '12

Jan Synacek wrote: > On 06/07/2012 03:00 PM, Howard Chu wrote: >> This code (and the original) don't seem to properly take deletes into account. It resets the ce counter to 0 on any delete op, but it should be decrementing based on the number of values provided. (And of course, it can only do that if the specified value is actually present in the attribute.) > I've updated the patch: > http://jsynacek.fedorapeople.org/openldap/jsynacek-20120619-constraint-coun… Thanks, committed to master with additional tweaks. > > Also, I've uploaded the tests I use: > http://jsynacek.fedorapeople.org/openldap/constraint-count-tests.tar.bz2 Looks like a nice start but you should look at the existing test script infrastructure, particularly the shell variables we already define, and make it conform. -- -- 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#7293) [PATCH] Add missing function declarations and make some functions static
by fumiyas＠osstech.jp 23 Jun '12

23 Jun '12

At Sat, 23 Jun 2012 05:42:15 -0700, Howard Chu wrote: > > Full_Name: SATOH Fumiyasu > > Version: master, 2.4.31 > > OS: > > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-function-declarations.patch > > Submission from: (NULL) (220.100.28.128) > > > > > > This patch adds missing function declarations to *.h, and make some > > functions and a global variable static. > > Thanks for the patch. In reviewing it, I see no reason to publish > ldap_pvt_sasl_getmechs or ldap_pvt_tls_check_hostname since neither is ever > referenced outside their defining source file. It looks like your addition of Thanks. > ldap_create_session_tracking_control is also a mistake, you should simply have > fixed the declaration ldap_create_session_tracking (which is a nonexistent name). Ah, right. > Did you have a particular need to use these functions? Aside from the No. I'm not an LDAP API user, thus I don't know which functions should be public or not. :-) > ldap_create_session_tracking_control typo I don't think it's worth the trouble > to tweak the others. -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/

1 0

Re: (ITS#7293) [PATCH] Add missing function declarations and make some functions static
by hyc＠symas.com 23 Jun '12

23 Jun '12

fumiyas(a)osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master, 2.4.31 > OS: > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-function-declarations.patch > Submission from: (NULL) (220.100.28.128) > > > This patch adds missing function declarations to *.h, and make some > functions and a global variable static. Thanks for the patch. In reviewing it, I see no reason to publish ldap_pvt_sasl_getmechs or ldap_pvt_tls_check_hostname since neither is ever referenced outside their defining source file. It looks like your addition of ldap_create_session_tracking_control is also a mistake, you should simply have fixed the declaration ldap_create_session_tracking (which is a nonexistent name). Did you have a particular need to use these functions? Aside from the ldap_create_session_tracking_control typo I don't think it's worth the trouble to tweak the others. -- -- 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#7316) [PATCH 5/5] MozNSS: do not retry when reading the pin from file
by jvcelak＠redhat.com 22 Jun '12

22 Jun '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: http://jvcelak.fedorapeople.org/openldap-patches/jvcelak-120622-0005-MozNSS… Submission from: (NULL) (209.132.186.34) If the password file contains invalid PIN for a certain token we should not retry the authentication, otherwise we can lock the token. Patch could not upload to OpenLDAP FTP server due to "No space left on device. Therefore I have uploaded the patch to fedorapeople.org. The patch is also available in 'moznss' branch of git://github.com/fcelda/openldap.git repository. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs