Re: (ITS#8860) searching issue
by ryan＠openldap.org
Hello,
The ITS is for reporting bugs in the software. For user support please
contact the openldap-technical(a)openldap.org mailing list.
This ITS will be closed.
On Sun, May 27, 2018 at 02:33:05PM +0000, bahaa.mosaad(a)barqsystems.com wrote:
>Full_Name: bahaa mosaad ali
>Version: 2.4.39-3.el7
>OS: redhat 7
>URL: https://drive.google.com/drive/my-drive
>Submission from: (NULL) (41.69.233.85)
>
>
>i have radius server and get openldap to connect with this (server) according to
>bind ruels success binding to ldap but when i search for some users without
>password i get all info about those users but if i search by command like this
>ldapsearch -x -W -D (user) dc= & password the error is always invalid
>credentials even if change the password more than one time
>
>according to this error when trying to authenticate users from radius it would
>be fail
>
>
>
>
5 years, 4 months
(ITS#8860) searching issue
by bahaa.mosaad＠barqsystems.com
Full_Name: bahaa mosaad ali
Version: 2.4.39-3.el7
OS: redhat 7
URL: https://drive.google.com/drive/my-drive
Submission from: (NULL) (41.69.233.85)
i have radius server and get openldap to connect with this (server) according to
bind ruels success binding to ldap but when i search for some users without
password i get all info about those users but if i search by command like this
ldapsearch -x -W -D (user) dc= & password the error is always invalid
credentials even if change the password more than one time
according to this error when trying to authenticate users from radius it would
be fail
5 years, 4 months
Re: (ITS#8616) olcSpNopresent and olcSpReloadHint can't be modified dynamically
by quanah＠symas.com
--On Thursday, May 24, 2018 6:49 PM +0100 Howard Chu <hyc(a)symas.com> wrote:
> quanah(a)symas.com wrote:
>> --On Tuesday, March 14, 2017 6:58 PM +0000 elecharny(a)symas.com wrote:
>>
>> Also fails for olcSpSessionLog (if it wasn't defined when the cn=config
>> db was loaded)
>
> Couldn't reproduce this, works for me.
I realized the issue I'd hit was with replicating cn=config when modifying
this attribute. Likely the missing matching rules issue that's tracked
under another ITS I need to address.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 4 months
Re: (ITS#8616) olcSpNopresent and olcSpReloadHint can't be modified dynamically
by hyc＠symas.com
elecharny(a)symas.com wrote:
> Full_Name: Emmanuel Lecharny
> Version: 2.4.44
> OS: CentOS
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (86.246.56.212)
>
>
> Adding either the olcSpNoPresent/olcSpReloadHint into a syncprov overlay is
> possible using slapd.d. It the values are set to TRUE, you can remove them. If
> you set them to FALSE, trying to remove the value get you an error 80.
>
> Second thing : set the value to TRUE (works), then change it to FALSE (works).
> Now, you are stuck : you can't revert it to TRUE or remove them.
>
> Third thing : set the value to FALSE (works), then you can't change it to TRUE
> or delete the attribute.
All of these are the same issue. Fixed in master.
>
> There is no other way that modifyin the ldif file to get it back on its feet.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 4 months
Re: (ITS#8859) Support backends without a database
by ondra＠mistotebe.net
On Tue, May 22, 2018 at 09:03:28AM +0000, h.b.furuseth(a)usit.uio.no wrote:
> On 21. mai 2018 17:07, ondra(a)openldap.org wrote:
>> In order to support the load balancer within the slapd process and integrate
>> correctly, we declare it to be a backend as that is the best match - allows us
>> to register all the callbacks that a subsystem like this needs. (...)
>
> Please comment SLAP_BFLAG_STANDALONE, explaining this, even though that goes
> against the surrounding coding style:-( Also maybe struct BackendInfo could
> use a comment about database backends vs database-less backends.
I've put a comment there. As for BackendInfo, there should be no
difference as far as I understand. But there is probably quite a bit of
context I'm still missing.
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
5 years, 4 months
Re: (ITS#8859) Support backends without a database
by h.b.furuseth＠usit.uio.no
On 21. mai 2018 17:07, ondra(a)openldap.org wrote:
> In order to support the load balancer within the slapd process and integrate
> correctly, we declare it to be a backend as that is the best match - allows us
> to register all the callbacks that a subsystem like this needs. (...)
Please comment SLAP_BFLAG_STANDALONE, explaining this, even though that goes
against the surrounding coding style:-( Also maybe struct BackendInfo could
use a comment about database backends vs database-less backends.
--
Hallvard
5 years, 4 months
(ITS#8859) Support backends without a database
by ondra＠openldap.org
Full_Name: Ondrej Kuznik
Version: master
OS:
URL: https://github.com/mistotebe/openldap/tree/ITS8859
Submission from: (NULL) (82.10.24.68)
In order to support the load balancer within the slapd process and integrate
correctly, we declare it to be a backend as that is the best match - allows us
to register all the callbacks that a subsystem like this needs. The only problem
is that slapd will skip startup for backends that are not used by at least one
database.
The linked patch deals with this limitation and a few bugs encountered along the
way (some code has not been exercised in a long time and has suffered from some
bitrot).
The support to provide backend global configuration was nominally present but
has never worked with cn=config. The first two patches deal with that. The last
patch introduces a new backend flag that indicates that it should be started up
even if there is no database using it.
IPR notice:
The linked files are derived from OpenLDAP Software. All of the modifications to
OpenLDAP Software represented in the following patches were developed Symas
corp. Symas corp. has not assigned rights and/or interest in this work to any
party. I, Ondrej Kuznik am authorized by Symas corp. to release this work under
the following terms.
Symas corp. 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.
5 years, 4 months
(ITS#8858) Walking the thread pool work queue
by ondra＠openldap.org
Full_Name: Ondrej Kuznik
Version: master
OS:
URL: https://github.com/mistotebe/openldap/tree/ITS8858
Submission from: (NULL) (82.10.24.68)
During reconfiguration, the load balancer might need to dispose of some
resources (connections, ...) as the new configuration invalidates their state.
Due to how pool pause is handled in libldap_r, tasks might still be queued in
there that reference those objects and need to be de-queued before we resume.
Most of the time, it is sufficient to record the cookie from pool_submit2 and
use pool_retract. At least in some phases of the load balancer implementation we
could have more than one task scheduled for the same object - with
reconfiguration being the rare case, optimising for it at the expense of the
common case does not feel right.
The linked patch is ready for review, it lets the caller examine the tasks with
a specified start_routine and have any of them retracted where appropriate.
5 years, 4 months
Re: (ITS#8852) slapd memory use grows continuously with non-delta syncrepl and modifying groups
by hyc＠symas.com
ryan(a)nardis.ca wrote:
> bisect identifies c365ac359e9c9b483b934c2a1f0bc552645c32fa as the commit
> that introduced this behaviour.
>
> 003dfbda574f37bbf1a2240f530ff9fa35ab0801 on RE24 (2.4.20)
>
> commit c365ac359e9c9b483b934c2a1f0bc552645c32fa
> Author: Howard Chu <hyc(a)openldap.org>
> Date: Sun Nov 22 04:42:00 2009 +0000
>
> ITS#6368 use dup'd entries in response queue
I've run your reproducer and see no memory leak. The response queue will
indeed grow without bound if the consumer runs slower than the provider, and
doesn't read responses fast enough. But in the case of this test script,
eventually the client finishes and the consumer catches up.
The provider's process size may not decrease, but that just means the malloc
implementation isn't returning freed memory to the kernel - it's not a leak.
This can be verified using mleak, and using SIGPROF to snapshot the memory
usage of the provider. The simplest way to force the memory use to grow is to
first suspend the consumer with SIGSTOP. Let the modify client run to
completion. mleak / SIGPROF will show a large amount of memory in use. Resume
the consumer with SIGCONT, let it run to completion, and then check with
SIGPROF on the provider again - all of the response queue memory is freed.
So, conclusively, there is no actual leak. But there's a problem with
sustained client modifications when the consumer is too slow. Our options here
are to configure a size limit on the response queue, and hang the client when
the limit is hit, or to return LDAP_BUSY to the client. Neither of these are
very attractive options.
Doing batched commits will speed up the consumer, but that feature is only in 2.5.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 4 months
