openldap-bugs

openldap-bugs@openldap.org

1 participants
21112 discussions

Re: ITS#3707 filters
by hyc＠symas.com 25 Dec '06

25 Dec '06

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I've had a patch for the Filter handling sitting here half-finished for >> quite a while. The intent is to preserve all of the original filter data >> so that it can be reused directly. > > This is now in HEAD. I haven't yet caught all the cases in get_ssa or > get_mra that drop the info when validation fails, but otherwise it's > usable. Instead of using the distinct SLAPD_FILTER_COMPUTED type for > filter components with unknown attributes, it now ORs the > SLAPD_FILTER_UNDEFINED flag onto the existing filter choice. This way > the original filter structure can be preserved. back-ldap's filter munging strategy still needs to be adapted to the new code. Probably it shouldn't use the filterstr at all. Any filter component with an unknown attribute is now logged with a '?' prefix, e.g. "(foo=a*b)" becomes "(?foo=a*b)". -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: ITS#3707 filters
by hyc＠symas.com 25 Dec '06

25 Dec '06

hyc(a)symas.com wrote: > I've had a patch for the Filter handling sitting here half-finished for > quite a while. The intent is to preserve all of the original filter data > so that it can be reused directly. This is now in HEAD. I haven't yet caught all the cases in get_ssa or get_mra that drop the info when validation fails, but otherwise it's usable. Instead of using the distinct SLAPD_FILTER_COMPUTED type for filter components with unknown attributes, it now ORs the SLAPD_FILTER_UNDEFINED flag onto the existing filter choice. This way the original filter structure can be preserved. > On a related note, RFC4511 changes the behavior of presence matching on > unknown attributes to be Undefined now instead of FALSE. So presumably > we should update our code accordingly. This is now in HEAD as well. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4792) not able to install Slapd i.e. when I install openldap it does'nt install server module
by azia＠techxact.com 25 Dec '06

25 Dec '06

Full_Name: Ahmad Zia Version: openldap-2.3.31 OS: Redhat ES 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.227.142.2) I have successfully compiled, make openldad but when I get to the point where I have to run "make test" it says cannot connect to the openldap server after timing out. When I use this command , I get the following: [root@TXDXB openldap]# rpm -qa | grep openldap openldap-devel-2.2.13-6.4E openldap-2.2.13-6.4E openldap-clients-2.2.13-6.4E its not listing openldap-server-2.2.13-6.4E and in my /etc/openldap directory I only have ldap.conf and I do not have slapd.conf, so what I gather so far is that I am not able to install the server module. I have used the parameter --enable-slapd with ./configure command but its still the same thing. Can you please tell me what am I doing wrong

1 0

Re: (ITS#4790) re23 hangs during shutdown after test033
by hyc＠symas.com 24 Dec '06

24 Dec '06

---- <ando(a)sys-net.it> wrote: > > Full_Name: Pierangelo Masarati > Version: re23 (2.3.31) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.28.220.33) > > > Apparently, one thread is unable to terminate correctly, so the test succeeds, > but then slapd hangs forever in ldap_pvt_thread_pool_destroy(). I couldn't > investigate this in depth right now, but I could easily reproduce it on two > different systems (different kernels and so), so I'm positive I can easily > reproduce it. This is a bad patch to connections_shutdown in RE23, there is a "continue" after checking for a client session that shouldn't be there. This line is not present in HEAD and the bug doesn't exist in HEAD. Strange that it got there since we just recently sync'd RE23 with HEAD's connection.c. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support

1 0

(ITS#4791) privileged connections handling in proxy backends
by ando＠sys-net.it 24 Dec '06

24 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando Privileged connections, under special circumstances, are cached and shared among client-side connections. This may result in very heavy traffic between the proxy and the remote server(s) on a single connection. As a consequence, multiple issues may arise: - heavy contention on the handler's resources - requests limitation at the remote server side on a single connection (this occurs if the remote server is OpenLDAP, but other implementations may follow similar design) - bottelneck whenever the shared connection needs be regenerated, i.e. because it expires (conn-ttl) As a workaround, a pool of privileged connections is proposed. A fixed maximum side pool is deisgned, so that whenever a privileged connection is requested, the related list of connections is walked looking for an idle one (refcnt == 0). If found, it's moved to the tail, to provide a simple round-robin mech to avoid reusing the same connections. If none is found, a new connection is generated, if use-temporary-conn is set to yes or the size limit is not reached, or the thread idles waiting for one to become available. If a new connection is created and there's room for it in the list, it's appended. Tests show a clear benefit on Linux when binding through back-ldap, since this nicely works around the bottleneck created by sharing the bind connection when operations are always proxied authz, to save network resources. Another benefit is represented by a clear smoothing of the response rates. Previously, frequent transients would occur, giving uneven response rates over time, while right now steady rates under steady conditions are observed. The patch is coming. p.

1 0

(ITS#4790) re23 hangs during shutdown after test033
by ando＠sys-net.it 24 Dec '06

24 Dec '06

Full_Name: Pierangelo Masarati Version: re23 (2.3.31) OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Apparently, one thread is unable to terminate correctly, so the test succeeds, but then slapd hangs forever in ldap_pvt_thread_pool_destroy(). I couldn't investigate this in depth right now, but I could easily reproduce it on two different systems (different kernels and so), so I'm positive I can easily reproduce it. p.

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it 24 Dec '06

24 Dec '06

hyc(a)symas.com wrote: > hyc(a)OpenLDAP.org wrote: > > >> I presume there's some kind of callback for registering new suffixes but I >> haven't looked very hard. >> > > This highlights some other issues lurking in here - back-monitor > basically doesn't deal with dynamic configuration well at all. It > assumes that all databases and overlays have been fully configured by > the time it starts - an assumption that was valid for old-style > slapd.conf use, but not with back-config. > > The monitor_subsys_database_init_one() function probably needs to be > split into separate pieces so that database and overlay info can be set > up and removed incrementally. > The point is that back-monitor has no clean means to detect what database is serving what naming context, since it was designed way ahead of back-config. So when time came to introduce monitor customization, the best mechanism I could find was the extended filter on the naming context. This is really creating trouble. The best solution would be to re-design back-monitor so that the database section mimics back-config using X-ORDERED 'SIBLING' style (and is updated accordingly, especially when entry renaming will be supported by back-config). The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get rid of those "cn=Database X", "cn=Overlay Y" stuff and so. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

ITS#3707 filters
by hyc＠symas.com 23 Dec '06

23 Dec '06

I've had a patch for the Filter handling sitting here half-finished for quite a while. The intent is to preserve all of the original filter data so that it can be reused directly. On a related note, RFC4511 changes the behavior of presence matching on unknown attributes to be Undefined now instead of FALSE. So presumably we should update our code accordingly. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by hyc＠symas.com 23 Dec '06

23 Dec '06

hyc(a)OpenLDAP.org wrote: > I presume there's some kind of callback for registering new suffixes but I > haven't looked very hard. This highlights some other issues lurking in here - back-monitor basically doesn't deal with dynamic configuration well at all. It assumes that all databases and overlays have been fully configured by the time it starts - an assumption that was valid for old-style slapd.conf use, but not with back-config. The monitor_subsys_database_init_one() function probably needs to be split into separate pieces so that database and overlay info can be set up and removed incrementally. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4789) can't add BDB database when monitoring
by hyc＠OpenLDAP.org 23 Dec '06

23 Dec '06

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc When back-monitor is active, attempting to add a bdb database thru cn=config fails in bdb_monitor_db_open. The call to mbe->register_entry_attrs() fails because the new database's suffixes aren't known to back-monitor: monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=dc=foo,dc=example,dc=com)": unable to find entry ====> bdb_cache_release_all backend_startup_one: bi_db_open failed! (-1) olcSuffix: value #0: <olcSuffix> failed startup (dc=foo,dc=example,dc=com)! send_ldap_result: conn=0 op=12 p=3 send_ldap_result: err=80 matched="" text="<olcSuffix> failed startup" I presume there's some kind of callback for registering new suffixes but I haven't looked very hard.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs