openldap-bugs August 2012

openldap-bugs@openldap.org

29 participants
100 discussions

Re: (ITS#7365) Server is unwilling to perform
by masarati＠aero.polimi.it 23 Aug '12

23 Aug '12

On 08/23/2012 11:36 AM, arunkumar_1123(a)yahoo.com wrote: > Full_Name: Arunkumar shanmugam > Version: 2.4.29 > OS: rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.83.248.38) > > > I discovered this while try to perform two paged search on a single connection . > ldap is not allowing me to perform two simultaneous paged request and getting > unwilling to perform (53) . i found this > http://www.openldap.org/lists/openldap-bugs/200406/msg00100.html thread while > searching for solution . Is this problem still exists ? . if so is there any > workaround ? This is the intended behavior, based on the current implementation of RFC2696. The workaround consists in using separate connections. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7365) Server is unwilling to perform
by arunkumar_1123＠yahoo.com 23 Aug '12

23 Aug '12

Full_Name: Arunkumar shanmugam Version: 2.4.29 OS: rhel5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.83.248.38) I discovered this while try to perform two paged search on a single connection . ldap is not allowing me to perform two simultaneous paged request and getting unwilling to perform (53) . i found this http://www.openldap.org/lists/openldap-bugs/200406/msg00100.html thread while searching for solution . Is this problem still exists ? . if so is there any workaround ?

1 0

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by hyc＠symas.com 22 Aug '12

22 Aug '12

hyc(a)symas.com wrote: > cmikk(a)qwest.net wrote: >> Full_Name: Chris Mikkelson >> Version: 2.4.32 >> OS: FreeBSD >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (204.147.85.37) >> >> >> When a back-mdb database is closed, the POSIX semaphores created when the mdb >> database was opened are left behind. This prevents a different user from opening >> the database. >> >> For example, if you run slapd as an unprivileged user, stop slapd, and do an >> offline slapcat as root, slapd will not start up again as that unprivileged >> user. The only ways to recover I've found are: > > This sounds like a bug in your platform's sem_open() syscall. If you first > started slapd as an unprivileged user, the semaphore should be owned by that > user. Running slapcat as root should not change the semaphore owner uid, and > the unprivileged owner should still be able to access the semaphore later. My mistake. Your patch looks good, committed. Thanks. > > Either that, or your description of the bug scenario is incomplete. I won't > commit your patch without a more complete understanding of the bug. > >> a) reboot the machine >> b) restore the database from the slapcat, ensuring that slapadd runs as the >> correct user, or >> c) write a small program to re-generate the semaphore names an remove them. >> >> The patch at: >> >> http://mikk.net/~chris/patches/0002-Remove-POSIX-semaphores-when-the-last-u… >> >> Attempts to upgrade the lockfile lock to exclusive when closing the environment. >> If that upgrade succeeds, it removes the semaphores. >> >> Patch has been tested on a BSD system. WIN32 has not been tested. > -- -- 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#7364) mdb: clean up POSIX semaphores on environment close.
by hyc＠symas.com 22 Aug '12

22 Aug '12

cmikk(a)qwest.net wrote: > Full_Name: Chris Mikkelson > Version: 2.4.32 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.147.85.37) > > > When a back-mdb database is closed, the POSIX semaphores created when the mdb > database was opened are left behind. This prevents a different user from opening > the database. > > For example, if you run slapd as an unprivileged user, stop slapd, and do an > offline slapcat as root, slapd will not start up again as that unprivileged > user. The only ways to recover I've found are: This sounds like a bug in your platform's sem_open() syscall. If you first started slapd as an unprivileged user, the semaphore should be owned by that user. Running slapcat as root should not change the semaphore owner uid, and the unprivileged owner should still be able to access the semaphore later. Either that, or your description of the bug scenario is incomplete. I won't commit your patch without a more complete understanding of the bug. > a) reboot the machine > b) restore the database from the slapcat, ensuring that slapadd runs as the > correct user, or > c) write a small program to re-generate the semaphore names an remove them. > > The patch at: > > http://mikk.net/~chris/patches/0002-Remove-POSIX-semaphores-when-the-last-u… > > Attempts to upgrade the lockfile lock to exclusive when closing the environment. > If that upgrade succeeds, it removes the semaphores. > > Patch has been tested on a BSD system. WIN32 has not been tested. -- -- 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#7350) aclparse.c acl_unparse() attrval empty DN
by hyc＠symas.com 22 Aug '12

22 Aug '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:9feb:ff03:4dbf:1141:9dad:2f88) > > > It seems to me, that the following acl statement isn't correctly unparsed within > aclparse.c: > > to dn.base="ou=persons,o=test" attrs=seeAlso val/distinguishedNameMatch="" by > users read > > > Starting slapd using loglevel 128 reports: > > Backend ACL: access to dn.base="ou=persons,o=test" > attrs=seeAlso > by users read > > I would have expected: > > Backend ACL: access to dn.base="ou=persons,o=test" > attrs=seeAlso > val/distinguishedNameMatch="" > by users read > > > As the empty DN is empty, the problem seems to be located in aclparse.c's > acl_unparse()'s statement > > if ( !BER_BVISEMPTY( &a->acl_attrval ) ) > > or even in the parse_acl() flagless spliting into left and right. > > > Sounds right. Thanks for the report, fixed in master. -- -- 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#7364) mdb: clean up POSIX semaphores on environment close.
by cmikk＠qwest.net 22 Aug '12

22 Aug '12

Full_Name: Chris Mikkelson Version: 2.4.32 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) When a back-mdb database is closed, the POSIX semaphores created when the mdb database was opened are left behind. This prevents a different user from opening the database. For example, if you run slapd as an unprivileged user, stop slapd, and do an offline slapcat as root, slapd will not start up again as that unprivileged user. The only ways to recover I've found are: a) reboot the machine b) restore the database from the slapcat, ensuring that slapadd runs as the correct user, or c) write a small program to re-generate the semaphore names an remove them. The patch at: http://mikk.net/~chris/patches/0002-Remove-POSIX-semaphores-when-the-last-u… Attempts to upgrade the lockfile lock to exclusive when closing the environment. If that upgrade succeeds, it removes the semaphores. Patch has been tested on a BSD system. WIN32 has not been tested.

1 0

Re: (ITS#7363) libmdb should use POSIX semaphores on non-apple BSD systems too.
by hyc＠symas.com 22 Aug '12

22 Aug '12

cmikk(a)qwest.net wrote: > Full_Name: Chris Miikkelson > Version: 2.4.32 > OS: FreeBSD > URL: > Submission from: (NULL) (204.147.85.37) > > > mdb on BSD-derived systems other than OS X also needs to use POSIX semaphores > for inter-process synchronization. I was working around this by adding > "-D__APPLE__" to CFLAGS, but that could have side-effects on some systems. The > following patch tells mdb to use posix semaphores if either BSD or __APPLE__ is > defined, which seems like a more targeted fix. > > http://mikk.net/~chris/patches/0001-Use-posix-semaphores-on-apple-and-bsd-s… > > Thanks for the patch, applied. -- -- 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#7363) libmdb should use POSIX semaphores on non-apple BSD systems too.
by cmikk＠qwest.net 22 Aug '12

22 Aug '12

Full_Name: Chris Miikkelson Version: 2.4.32 OS: FreeBSD URL: Submission from: (NULL) (204.147.85.37) mdb on BSD-derived systems other than OS X also needs to use POSIX semaphores for inter-process synchronization. I was working around this by adding "-D__APPLE__" to CFLAGS, but that could have side-effects on some systems. The following patch tells mdb to use posix semaphores if either BSD or __APPLE__ is defined, which seems like a more targeted fix. http://mikk.net/~chris/patches/0001-Use-posix-semaphores-on-apple-and-bsd-s…

1 0

Re: (ITS#7362) back-mdb: slapadd -q fails
by quanah＠zimbra.com 22 Aug '12

22 Aug '12

--On Wednesday, August 22, 2012 4:44 PM +0000 quanah(a)zimbra.com wrote: > --On Wednesday, August 22, 2012 4:40 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > >> > > data.mdb is zero sized: > > mail:/opt/zimbra/data/ldap/mdb/db # ls -l > total 4 > -rw------- 1 zimbra zimbra 0 2012-08-22 12:32 data.mdb > -rw------- 1 zimbra zimbra 8192 2012-08-22 12:32 lock.mdb > > mail:/opt/zimbra/data/ldap/mdb/db # df -h . > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/system-zimbra > 39G 33G 6.7G 83% /opt/zimbra > > > maxsize is 84GB, but the actual DB will be < 26MB when it is finished > being created. Is this because maxsize > total free disk space? This is definitely not an OpenLDAP bug. Apparently some OSes block max allocation, even if blocking it is disabled. This particular server is running SLES11 SP1: Linux mail 2.6.32.49-0.3-default #1 SMP 2011-12-02 11:28:04 +0100 x86_64 x86_64 x86_64 GNU/Linux Something at the OS level is blocking the mdb memory allocation. This same issue does not occur on other SLES11 installations we have, so I'm somewhat at a loss to explain it. --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#7362) back-mdb: slapadd -q fails
by quanah＠zimbra.com 22 Aug '12

22 Aug '12

--On Wednesday, August 22, 2012 4:40 PM +0000 openldap-its(a)OpenLDAP.org wrote: > data.mdb is zero sized: mail:/opt/zimbra/data/ldap/mdb/db # ls -l total 4 -rw------- 1 zimbra zimbra 0 2012-08-22 12:32 data.mdb -rw------- 1 zimbra zimbra 8192 2012-08-22 12:32 lock.mdb mail:/opt/zimbra/data/ldap/mdb/db # df -h . Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-zimbra 39G 33G 6.7G 83% /opt/zimbra maxsize is 84GB, but the actual DB will be < 26MB when it is finished being created. Is this because maxsize > total free disk space? --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

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2012