Re: (ITS#7365) Server is unwilling to perform
by masarati＠aero.polimi.it
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
10 years, 7 months
Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by hyc＠symas.com
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...
>>
>> 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/
10 years, 7 months
Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by hyc＠symas.com
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...
>
> 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/
10 years, 7 months
Re: (ITS#7350) aclparse.c acl_unparse() attrval empty DN
by hyc＠symas.com
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/
10 years, 7 months
(ITS#7364) mdb: clean up POSIX semaphores on environment close.
by cmikk＠qwest.net
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...
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.
10 years, 7 months
Re: (ITS#7362) back-mdb: slapadd -q fails
by quanah＠zimbra.com
--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
10 years, 7 months
Re: (ITS#7362) back-mdb: slapadd -q fails
by quanah＠zimbra.com
--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
10 years, 7 months
