openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by tedcheng＠symas.com 12 Apr '13

12 Apr '13

Full_Name: Ted C. Cheng Version: HEAD OS: Solaris 8 URL: https://dl.dropboxusercontent.com/u/94235048/fix_send_cli_cred.patch Submission from: (NULL) (76.174.250.179) Importing fix from Symas #2230: On platforms, such as Solaris 8, that do not support functions for getting client credential, client sends a message and fd for server to derive euid/egid. The server-side logic for deriving client credential was buggy. This patch introduces sockaddr_un_cmp() to compare the socket path names, ignoring redundant "/" in the path, and only checks S_IFIFO mode. This patch has been tested on Solaris 8 and regression-tested fine on Solaris 10.

1 0

Re: (ITS#7574) slapo-unique not enforcing uniqueness
by quanah＠zimbra.com 12 Apr '13

12 Apr '13

--On Friday, April 12, 2013 5:48 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, April 12, 2013 5:43 PM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: RE24 4/12/2013 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.39.181) > > Also the following modify succeeds when it should fail: > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w > zimbra dc=test zimbraID > dn: dc=test,dc=com > zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc > > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w > zimbra dc=example zimbraId > dn: dc=example,dc=com > zimbraId: 0c18e59d-fdd7-40b2-abff-134b118e6cf9 > > zimbra@zre-ldap002:~$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra > dn: dc=example,dc=com > changetype: modify > replace: zimbraId > zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc > > modifying entry "dc=example,dc=com" I found it has entirely to do with brand new entries since slapd was last started. unique simply won't enforce on any data added after slapd was started. Restarting slapd results in the correct behavior. --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#7574) slapo-unique not enforcing uniqueness
by quanah＠zimbra.com 12 Apr '13

12 Apr '13

--On Friday, April 12, 2013 5:43 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 4/12/2013 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.39.181) Also the following modify succeeds when it should fail: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra dc=test zimbraID dn: dc=test,dc=com zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra dc=example zimbraId dn: dc=example,dc=com zimbraId: 0c18e59d-fdd7-40b2-abff-134b118e6cf9 zimbra@zre-ldap002:~$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra dn: dc=example,dc=com changetype: modify replace: zimbraId zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc modifying entry "dc=example,dc=com" zimbra@zre-ldap002:~$ --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#7574) slapo-unique not enforcing uniqueness
by quanah＠OpenLDAP.org 12 Apr '13

12 Apr '13

Full_Name: Quanah Gibson-Mount Version: RE24 4/12/2013 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.39.181) In current RE24, when using the back-mdb backend, uniqueness is no longer enforced. This worked correctly up until at least 2.4.33. dn: olcOverlay={1}unique objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {1}unique olcUniqueURI: ldap:///?mail?sub olcUniqueURI: ldap:///?zimbraId?sub olcUniqueURI: ldap:///?DKIMSelector?sub so I force uniqueness on "DKIMSelector" It is indexed eq: olcDbIndex: DKIMSelector eq However, adding data for it succeeds when it should be rejected: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra DKIMSelector=ABCD DKIMSelector dn: dc=test,dc=com DKIMSelector: ABCD dn: dc=example,dc=com DKIMSelector: ABCD

1 0

Re: (ITS#7573) back-perl not working with cn=config
by quanah＠zimbra.com 11 Apr '13

11 Apr '13

--On Thursday, April 11, 2013 6:20 PM +0000 benintechnologies(a)yahoo.fr wrote: > Like I said, if I set back-perl up in slapd.conf mode and then convert it > to cn=config, everything works fine. So how does the ldif generated by slaptest differ from what you are loading? If you slapcat your config that doesn't work, and compare it to the slapcat of what was generated from slaptest, what are the differences? Can you provide a gdb backtrace of the segmentation fault? --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#7573) back-perl not working with cn=config
by benintechnologies＠yahoo.fr 11 Apr '13

11 Apr '13

Full_Name: Ben Version: 2.4.34 OS: Debian 6.0.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (41.79.217.116) Hi, I'm unable to set up a back-perl backend directly in cn=config mode. However, if I set it up in slapd.conf mode, and then convert it to cn=config mode, it works fine. It's not convenient, because I have to set all my perl backends up before converting to cn=config. Here's the ldif file I'm using to set up a back-perl backend in cn=config mode (it's inspired from the files I get by converting slapd.conf into cn=config with slaptest) # Load dynamic backend modules dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/local/libexec/openldap olcModuleload: back_perl.la # Database settings dn: olcDatabase=perl,cn=config objectClass: olcDatabaseConfig objectClass: olcDbPerlConfig olcDatabase: perl olcSuffix: dc=mydomain,dc=org olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=mydomain,dc=org olcRootPW:: c2VjcmV0 olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcPerlModulePath: /usr/local/etc/openldap/perl olcPerlModule: SampleLDAP olcPerlFilterSearchResults: FALSE And here's what I get when I try to load the file: ldapadd -Y EXTERNAL -H ldapi:/// -f perl-backend.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" adding new entry "olcDatabase=perl,cn=config" ldap_result: Can't contact LDAP server (-1) After that, if I start OpenLDAP I get a segmentation fault: root@ldap:/tmp# /usr/local/libexec/slapd -u openldap -g openldap -h "ldap:/// ldapi:///" -d 16383 . 51585496 perl backend db init Segmentation fault Like I said, if I set back-perl up in slapd.conf mode and then convert it to cn=config, everything works fine. Ben

1 0

ITS#6365 Fwd: RE: truncated slapcat output
by hyc＠symas.com 11 Apr '13

11 Apr '13

Fix verified. -------- Original Message -------- Subject: RE: truncated slapcat output Date: Thu, 11 Apr 2013 07:15:17 +0000 From: Hummel, Wolfgang <wolfgang.hummel(a)hp.com> To: Howard Chu <hyc(a)symas.com> Hello Howard, we tested your fix for truncated slapcat and it works fine. Please see test report below. As I am not familiar with your processes in commenting on bugfixes could you use the attached test report and commit the fix so it will become part of next release ? Thanks a lot for your support Regards Wolfgang Hummel Test execution timeframe: April 9th and 10th 2013 Test platform: Hardware HP DL380 G5, 32 GB Memory, 2 Quadcore CPUs OS RedHat 5.1 OpenLDAP 2.4.32 without / with slapcat truncate bugfix bdb backend Test setup: - Subscriber profile DB with 1 Mio. entries, each with 10 attributes Test execution: - ldapbenchmark.pl executing ~ 5 ldapmodifies and ~ 2 ldapsearches / second - slapcat_vfhu_vm_profiles.sh running slapcat in a cycle and counting entries Test result without slapcat truncate bugfix: - 1826 measurements of entry number - 23 events with truncated slapcat output - slapcat return code was always 0 ! Test result with slapcat truncate bugfix: - 1647 measurements of entry number - 0 events with truncated slapcat output script to measure it: #!/bin/bash # run slapcat forever and always count number of entries # they should always be the same while : do slapcat -b ou=vm,ou=profiles,ou=xxxx,c=hu,o=yyyy|grep "^dn:"|wc -l >>vfhu_vm_entries.txt echo "Slapcat Return Code: $?; `date`">>vfhu_vm_entries.txt sleep 1 done log snippet with bug fix: Slapcat Return Code: 0; Wed Apr 10 22:12:42 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:05 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:28 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:13:52 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 22:14:16 CEST 2013 1000001 log snippet without bugfix: 1000001 Slapcat Return Code: 0; Wed Apr 10 01:01:45 CEST 2013 319284 Slapcat Return Code: 0; Wed Apr 10 01:02:07 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:03:15 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:03:42 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:04:09 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:04:37 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:05:04 CEST 2013 437990 Slapcat Return Code: 0; Wed Apr 10 01:05:16 CEST 2013 146790 Slapcat Return Code: 0; Wed Apr 10 01:05:21 CEST 2013 72688 Slapcat Return Code: 0; Wed Apr 10 01:05:25 CEST 2013 1000001 Slapcat Return Code: 0; Wed Apr 10 01:05:50 CEST 2013 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Dienstag, 26. März 2013 18:09 To: Hummel, Wolfgang Subject: Re: truncated slapcat output Hummel, Wolfgang wrote: > Hello Howard, > > we are facing in production of our major customer VF the same problems as > described in > > http://www.openldap.org/lists/openldap-technical/201301/msg00232.html > > We are using back-bdb and slapcat to create nightly ldif backups of all DBs > > where 2 of them each contains ~ 40 Mio. entries. > > Even though write traffic is low when the slapcat job runs, every 1 - 2 weeks > > output is truncated without error msg or error return code which creates problems > > for subsequent batch jobs. > > Therefore a slapcat that retries like slapd if a page is locked would be > > really important for us. > > 2 Questions: > > - Is the slapcat retry mechanism the fix you described in > http://www.openldap.org/lists/openldap-technical/201301/msg00232.html ? The patch for ITS#6365 was committed to master commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 Author: Howard Chu <hyc(a)openldap.org> Date: Thu Feb 7 18:23:25 2013 +0000 ITS#6365 wait for read locks in tool mode > - When will it be available in OpenLDAP ? When somebody follows up to the ITS and confirms that the patch fixes the issue. So far nobody has followed up. You're welcome to test and followup. > > Regards > > Wolfgang Hummel > > ---------------------------------------------------------- > > Postal Address: Hewlett-Packard GmbH > > Wolfgang Hummel > > Enterprise Services > > _/ Communication & Media Solutions > > _/ Herrenberger Str. 140 > > _/_/_/ _/_/_/ 71034 Böblingen > > _/ _/ _/ _/ Phone: +49 7031 14-7375 > > _/ _/ _/_/_/ Fax: +49 711 18562024 > > _/ mobile: +49 151 14751791 > > _/ E-Mail: wolfgang.hummel(a)hp.com > <mailto:wolfgang.hummel@hp.com> > > ---------------------------------------------------------- > > http://www.hp.com/de > > Hewlett-Packard GmbH, Herrenberger Str. 140, 71034 Böblingen > > Geschäftsführer: Volker Smid (Vorsitzender), Martin Kinne, Heiko Meyer, Ernst > Reichart, Rainer Sterk Vorsitzender des Aufsichtsrates: Jörg Menno Harms Sitz > der Gesellschaft: Böblingen, Amtsgericht Stuttgart HRB 244081, WEEE-Reg.-Nr. > DE 30409072 > -- -- 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#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 11 Apr '13

11 Apr '13

Full_Name: Claude Brisson Version: HEAD OS: linux 64 URL: ftp://ftp.openldap.org/incoming/0001-fix-MDB_GET_MULTIPLE-and-MDB_NEXT_MULT… Submission from: (NULL) (84.103.74.130) In a db with MDB_DUPSORT flag, when there is only one DUP data for a key, F_DUPDATA is not set for this key, and there is no sub-cursor. In this case, the current behaviour of MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE is broken because they make the assumption that there is always a sub-cursor for DUP data, which is only true for keys with more than one DUP data. This patch address this specific issue. Notice: I, Claude Brisson, 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#7568) [Patch] Minor documentation fixes
by hyc＠symas.com 10 Apr '13

10 Apr '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.132.186.34) > > > I'm attaching two patches that fix minor documentation issues in ldap.conf.5 and > slaptest's usage output. Thanks, added to master. > http://jsynacek.fedorapeople.org/openldap/jsynacek-20130409-0001-Fix-typos-… > http://jsynacek.fedorapeople.org/openldap/jsynacek-20130409-0002-Add-Q-to-s… Personally I don't see much point to -Q here; the purpose of slaptest is to tell you what errors are there. With -Q you get no useful information when an error occurs. Judging from the fact that no one has noticed this omission in the 6 years since -Q was added, I don't believe this particular feature has been of any importance one way or the other. -- -- 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#7569) Patch: fixed a group enumeration bug in nssov
by tedcheng＠symas.com 10 Apr '13

10 Apr '13

Full_Name: Ted C. Cheng Version: HEAD OS: Solaris 8, 10, Linux URL: https://dl.dropbox.com/u/94235048/symas2255.patch Submission from: (NULL) (76.174.250.179) Importing a patch from Symas #2255 that fixed a group enumeration bug in nssov. The "rc" variable was not initialized in nssov write_group function. Theoretically, this bug should affect all platforms. Solaris 8 (64-bit) caught the bug because rc got a non-zero value when not initialized.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs